On Mon, Jun 26, 2006 at 11:13:32AM -0500, Miller, Mike (OS Dev) wrote: > All, > Sorry to come in late and top post. I've been out of the office and I'm > trying to get to the gist of this issue. > Exactly what is the problem? I'm not familiar with kdump so I don't have > a clue about what's going on. Hi Mike, Kdump is a kernel crash dumping mechanism which is built on top of kexec on panic functionality. http://lse.sourceforge.net/kdump/ After a system crash, a second kernel boots from a reserved memory without going through the BIOS. This second kernel captures the memory snapshot of the crashed kernel. Devices are not shutdown after the first kernel crash hence while second kernel is initializing device might very well be oprational and sending interrupts. So the moment a driver loads underlying device might send an interrupt indicating completion of a command issued from the context of crashed kernel. Driver does not know anything about it and often crashes or raises a BUG() as this is anomalous. Ideal thing probably would be to soft reset the deivce before going ahead with rest of the initilization so that device flushes the messages issued from the context of the previous kernels and lower the interrupt line. Hope this gives some context. > There are a couple of reset features supported by _some_ cciss > controllers. I'd have to go back to the open spec to see whats in the > public domain. We're trying to get the open spec updated and more > complete but we're waiting on the lawyers. :( > Thanks Vivek - : send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html