RE: [2.4.21] Spurious ABORTs

[James Bottomley <James.Bottomley@SteelEye.com>]

On Tue, 2005-09-27 at 15:48 -0400, Bagalkote, Sreenivas wrote:
> >1. you do clustering, so a reset request could be from a 
> >reservation breaking protocol
>
> I don't have clustering setup. So this is definitely not the reason.

You might not, but others do.  If you return success to a reset request
without doing anything then the device will stay reserved by the other
system.  i.e. you'll break clustering setups.

> >2. The fact that the eh activated indicates something went 
> >wrong.  If you take no corrective action and the test unit 
> >ready that follows the reset fails or times out then the 
> >device will be taken offline.
> >
> 
> Heavy IOs are going on in the FW while it is rebuilding RAID arrays.
> We expect some of the commands to timeout. But the key is recover
> gracefully. I see that FW is completing _all_ the commands albeit 
> after timing out. When the reset handler is called after all the
> commands are out of the door, I simply return success. Can this
> potentially cause any issues?

As long as the Test Unit Ready that follows the reset succeeds, then no,
this will work and it shouldn't cause any issues other than the
clustering one.

James