On Mon, Jun 26, 2006 at 11:51:52AM -0500, Miller, Mike (OS Dev) wrote:
[..]
> >
> >
> > kdump or taking crash dumps using the kexec on panic
> > mechanism could be called a drivers worst nightmare. In the
> > latest distros this is becoming the way crash dump style
> > information is captured.
> >
> > Because the initial kernel is broken we do a jump into
> > another kernel that is sufficient to record a crash dump.
> > That second kernel initializes the hardware from whatever
> > random state the first kernel left the drivers in. That
> > first kernel is not permitted to do any device shutdown activities.
> >
> > The problem is that a command the running instance of the
> > driver did not initiate completes. At least if I read Vivek
> > patch 2/2 correctly.
> >
> > So we have three options.
> > - reset the card during initialization.
> > - handle the case of a command we did not initiate completing.
> > - mark the driver/card as impossibly hopeless for use in a crash
> > dump scenario.
> >
> >
> > Eric
>
> Thanks Eric, that helps me understand. Section 8.2.2 of the open cciss
> spec supports a reset message. Target 0x00 is the controller. We could
> add this to the init routine to ensure the board is made sane again but
> this would drastically increase init time under normal circumstances.
> And I suspect this is a hard reset, also. Not sure if that would
> negatively impact kdump.
As long as driver is able to initialize the device and continue working
kdump is not impacted whether it is a hard reset or soft reset.
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]
