--------------------------------
BRAVO!!!!!!!!!!!!!!!!!!!!!!!!!!!
--------------------------------
You seem ready to deal with ncr/sym drivers maintainance if I
decide to give up the Linux project. :-)
The test against BUS connected was kind of check for safety, but indeed
it is not that smart. Will study the situation and let you know.
For now, I am not sure if removing it is really safe.
Your bug tracking has been kind of perfection. Obviously, if a bug has
to be stated, it is a driver bug. But, in normal situations, no SCSI
interrupts should happen, so it cannot be stated as a serious bug.
If the driver recovers, then it is just usual "room for improvement",
in my opinion. :-)
Regards,
G�rard.
On Thu, 22 Jul 1999, D. Lance Robinson wrote:
> Gerard,
>
> Here is what seems to be happening.
>
> 1) Send Write command to device X, it disconnects.
> 2) Issue Test Test Unit Ready command to non-existant device Y.
> 3) This times out and goes into the interrupt service routine (isr).
> 4) The isr reads the status bits. Somehow the chip is enabled.
> 5) Device X reselects (before the isr is finished)
> 6) The isr thinks it is connected because of the error.
> 7) The isr does a reset.
> 8) More bad things happen.
>
> NOTE:
> To test this theory, I changed ncr_recover_scsi_int() with the following
> code...
>
> if (scntl1 & ISCON) {
> if (hsts==HS_SEL_TIMEOUT)
> printk( "SEL Timeout, but host is connected!?\n");
> goto reset_all;
> }
>
> The message does get triggered.
>
> Any clues on how to prevent the reconnect before the error handler has
> done its thing? Is this a chip bug? NOTE: where the printk statement
> is, I tried to call ncr_complete() from there. That helped some, but the
> middle scsi layer showed some timeout messages.
>
> <>< Lance.
>
>
> Gerard Roudier wrote:
> >
> > 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]
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
