Hello, On Mon, Mar 14, 2011 at 03:25:04PM -0700, Andrew Morton wrote: > The ata driver detected an error and the kernel immediately oopsed > somewhere in the CPU scheduler. I'd be suspecting a bug somewhere in a > rarely-used ata/block codepath. Eh, unlikely. The path is frequently traveled (shared with probing path) and I can't really think of anything which could affect scheduler like that. There's nothing really exotic there. > On Sun, 13 Mar 2011 00:31:38 GMT > > Under somewhat heavy load, I first had problems with eth0 going haywire: Pretty please always attach full kernel log including the boot messages when reporting a kernel bug. > > [1041371.782410] e1000e 0000:04:00.0: eth0: Reset adapter > > [1041415.765409] e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow > > Control: None So, eth0 is acting up. > > I switched the cables, took out the module, renamed eth1 to eth0 and added > > things back. But 15 minutes later or so, I got the following oops: > > > > [1041979.906665] ata9.00: exception Emask 0x32 SAct 0x0 SErr 0x1000400 action > > 0x6 frozen > > [1041979.915101] ata9.00: irq_stat 0x18000000, host bus error, interface fatal > > error and then the ATA controller is reporting data corruption on the host bus, not the ATA bus - that is, data is getting corrupted while being transported between the memory and the controller. > > [1041980.002432] BUG: unable to handle kernel NULL pointer dereference at > > 0000000000000181 > > [1041980.003006] IP: [<ffffffff8102dd5c>] dequeue_task_fair+0x20/0x227 and then the system goes belly up in an unrelated code path. Looks like malfunctioning hardware to me. My first suggestion would be trying a different PSU. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
