James Bottomley <James.Bottomley@xxxxxxxxxxxx> 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 - : 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
