Received from Mark Salyzyn:

Add code to abort outstanding management ioctl fibs when the blinkLED recovery
is performed. This code is 'clunky' and does not have any real feedback in that
the reset could progress before the user application has gotten it's
notification of command completion. We put a schedule() call to delay just the
right amount for most cases, because we tried a spin and still managed to find
cases where we would spin forever waiting for the management application to
acknowledge the impending doom surrounding the cause of the BlinkLED. Will
cause an oops in the context of the management application if we proceed too
quickly. I view this as the lesser of many evils since currently if there are
outstanding management ioctls during a need to reset/recover the adapter, the
management application just locks up and waits forever. The best practices fix
for this problem not going to be simple or easy (at least the fixes I imagine
today); and we found a balance between the needs of the driver to proceed, and
the applications that locked or confused that would hold back the driver. I
just do not like the idea of a kernel oops in an application to deal with low
priority, sluggish or misbehaving applications.
Signed-off-by: NMark Haverkamp <markh@osdl.org>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>