On Wed, 21 Jul 1999, D. Lance Robinson wrote:
> Hi Gerard & others,
>
> Using a Symbios/LSI 53c895 chip and the sym53c8xx driver, I am trying to
> scan the bus for newly added devices using the
>
> echo "scsi add-single-device 0 0 id 0 " >/proc/scsi/scsi
>
> technique. This generally works on an idle bus (doesn't always see a
> device), but bad things happen when there is activity on the bus when
> the 'add' command is issued. A bus reset get generated when a device
> reselects the bus. And this can happen several times when trying to
> 'add' (probe) a non-existant device.
>
> Here is a scenario of what is happening (with the help of a SCSI
> analyzer.)
Then I have the only option to trust you. ;-)
> 1) One or more commands get queued up in device X.
> 2) The 'add-single-device' command is issued for non-existant device Y.
> 3) Exactly what happens now is a bit fuzzy
> 4) Device X reselects the host, and sends the 0x80 Identify message
> 5) The SCSI Bus is RESET.
> 6) Loops back to 4 for zero or more times
Strange, but probably quite uncommon and unusual situation. :)
Will be pleased to know if, at least, the thing does recover from the
problem.
> NOTE: I am using Seagate Barracuda devices (ST39102LC) and this is on a
> PowerPC system.
>
> Any ideas ?
Absolutely none.
The scenario that should happen should be that the initiator handles the
selection timeout procedure using compliant timings and that the target
that wants to reselect also uses compliant timings for detecting the BUS
free phase, then rearbitrating for the BUS and then reselecting and
sending its message.
Also, the controller SCSI core must latch the right number of the target
that reselected, etc..., etc..., etc...
I am interested in all the data you have on the problem (kernel messages,
SCSI traces, other informations)
Thanks for the report.
Regards,
G�rard.
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
