> Eddie Williams <[EMAIL PROTECTED]> wrote:
> > What problem is trying to be solved with the Bus Device Reset?
>
> Ensure that the drive is not in a bizarre negociated speed.
>
> Example:
>
> host negociates ultra-wide with disk
> disk is disconnected from bus, but not powered down
> bus is reset for some reason
> disk is reconnected, still think ultra-wide is the norm
> host does inquiry (*)
> disk hangs
>
> (*) if the first command does a new negociation, then it's not a problem.
>
> I agree that this is a rare situation.
In the scenario you paint why would there be a add-single-device? The device
was already connected to the system so you wouldn't have to do an add? Or are
you saying there is something else going on while the device is disconnected
from the bus? I believe the scenario you describe the only reasonable
response is when the disk hangs the SCSI drivers gets a timeout and issues a
bus device reset. If the device is really hosed it wont take so a bus reset
is needed. That should clear everything and when the IO is retried all goes
well.
>
> But today, it looks like in some cases the backwards situation can arise:
> the kernel seems to think the device is in ultra wide just after
> add-single-device. If the device was powered down, well, ...
That sounds to me like an outright bug. An add-single-device should cause the
mid-level and low-level drivers to start from scratch.
>
> My idea with the Bus Device Reset was to force the host adapter
> to understand that he has to redo its negociation, since I don't
> think you can tell him that another way.
I don't think the solution to fix a bug in a driver is to issue a reset to get
around it. The bug should be fixed so that after an add-single-device
asynchronous is negotiated.
Eddie
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
