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

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

James Bottomley <James.Bottomley@SteelEye.com> writes:

> On Mon, 2006-06-26 at 11:39 -0600, Eric W. Biederman wrote:
>> In the general case resets are trivial operations.  In scsi land 
>> things are different.  So a solution appropriate to that domain may
>> be appropriate.
>
> That's not necessarily true. You're talking about board level resets
> here.  Some devices take quite a while to reboot after being reset ...
> particularly the complex ones with internal operating system type
> firmware ..

Agreed.  I had forgotten about the firmware case as opposed to the device
case.  It is still true that we are mostly talking the scsi domain, when
we are talking about boards with their own OS's.

The important point is to find a way to harden drivers so the driver can
initialize when the device is in a fairly random state and work.  Resets are
the obvious way to get there.  There may be other cheaper ways, like
forcefully setting all of the registers into a know good state.

But I still stand behind the fact that for most devices a reset is a trivial
operation, that takes an insignificant amount of time.  Devices with slow
firmware and devices with big slow disks attached to them are not most devices.

So for most devices the advice can really be just reset it already.  For
scsi devices where we frequently have the weird slow reset case after a
little more experience of what has to be done we can give better domain
specific advice.

Eric