Re: [Fastboot] [RFC] [PATCH 2/2] kdump: cciss driver initialization issue fix

[ebiederm@xmission.com (Eric W. Biederman)]

"Miller, Mike (OS Dev)" <Mike.Miller@hp.com> writes:

> 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. 
> 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. :(


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