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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
