linux-kernel - Re: 2.6.21-rc7-mm1 BUG at kernel/sched-clock.c:175 init_sched

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <46354620.4060902@gmail.com>
Date:	Mon, 30 Apr 2007 10:28:00 +0900
From:	Tejun Heo <htejun@...il.com>
To:	"Berck E. Nash" <flyboy@...il.com>
CC:	Andrew Morton <akpm@...ux-foundation.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Jeff Garzik <jeff@...zik.org>, linux-ide@...r.kernel.org
Subject: Re: 2.6.21-rc7-mm1 BUG at kernel/sched-clock.c:175 init_sched_clock()

Hello.

Berck E. Nash wrote:
> Okay, while this patch allows my system to boot, it eventually crashed.
>  Unfortunately, I don't know enough to know if this crash is at all
> related, but it seems like it might be?
> 
> [ 1314.960784] irq 316: nobody cared (try booting with the "irqpoll" option)
> [ 1314.967602]
> [ 1314.967602] Call Trace:
> [ 1314.971566]  [<ffffffff8025dae3>] dump_trace+0xb6/0x3d6
> [ 1314.976809]  [<ffffffff8025de3f>] show_trace+0x3c/0x52
> [ 1314.981963]  [<ffffffff8025de6a>] dump_stack+0x15/0x17
> [ 1314.987118]  [<ffffffff802993c8>] __report_bad_irq+0x38/0x7c
> [ 1314.992790]  [<ffffffff802995db>] note_interrupt+0x1cf/0x215
> [ 1314.998463]  [<ffffffff8029a037>] handle_edge_irq+0x104/0x133
> [ 1315.004231]  [<ffffffff8025f4e1>] do_IRQ+0x6d/0xd5
> [ 1315.009039]  [<ffffffff80255071>] ret_from_intr+0x0/0xa
> [ 1315.014281]  [<ffffffff8024e88b>] mwait_idle+0x46/0x4b
> [ 1315.019433]  [<ffffffff802422f4>] cpu_idle+0x87/0xaa
> [ 1315.024414]  [<ffffffff8025c988>] rest_init+0x49/0x4b
> [ 1315.029489]  [<ffffffff805dca5d>] start_kernel+0x291/0x29c
> [ 1315.034989]  [<ffffffff805dc13a>] _sinittext+0x13a/0x141
> [ 1315.040323]
> [ 1315.041813] handlers:
> [ 1315.044090] [<ffffffff803e4951>] (ahci_interrupt+0x0/0x47a)
> [ 1315.049722] Disabling IRQ #316
> [ 1345.037254] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2
> frozen
> [ 1345.044333] ata1.00: cmd c8/00:08:ff:53:00/00:00:00:00:00/e2 tag 0
> cdb 0x0 data 4096 in
> [ 1345.044334]          res 40/00:00:76:5a:00/00:00:00:00:00/e0 Emask
> 0x4 (timeout)
> [ 1345.059832] ata3.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x2
> frozen
> [ 1345.066919] ata3.00: cmd 60/08:00:bb:26:0a/00:00:09:00:00/40 tag 0
> cdb 0x0 data 4096 in
> [ 1345.066920]          res 40/00:00:00:4f:c2/00:00:00:00:00/00 Emask
> 0x4 (timeout)
> [ 1345.389731] ata1: soft resetting port
> [ 1345.396451] ata3: soft resetting port

Hmmm... Once properly initialized, ahci is highly unlikely to cause
runaway IRQs which results in nobody cared.  It has proper IRQ mask and
pending bits allowing the driver to reliably detect when and why the
controller is raising interrupt and disable it if necessary.  Can you
try without the NVIDIA module?

-- 
tejun

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/