lkml.org 
[lkml]   [1999]   [Feb]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: ncr53c8xx SCSI driver locks up computer after timeout message


On Tue, 23 Feb 1999, Bradley M. Kuhn wrote:

> Gérard, thank you so much for writing back to me!
>
> Thus spoke Gérard Roudier:
> > > As the README for the ncr53c8xx suggests, I have configured the drive with:
> > > - only asynchronous data transfers
> > > - tagged commands disabled
> > > - disconnections not allowed
> >
> > The README also suggests to first check that your SCSI bus is compliant to
> > specs. Let me assume you did it. :)
>
> I surely did. It's all brand new equipment, terminated properly (my older
> problems were due to poor termination, which is now clearly fixed (I had
> severe data loss before, and frequent. Now, things are very stable except
> for this lock-up problem)).
>
> > > Thus, I am not using any advanced features that might be buggy.
> >
> > IMO, mixing a JAZ device with a fine Fast-40 Hard disk on the same SCSI
> > BUS is kind of suicide, since the JAZ devices are known to be crappily
> > firmwared.
>
> Hmmm... do you think this could be the root cause of my problem? Is it

May-be not if you aren't using it when the problem occured.

> worth using a spare older SCSI card of a different brand to handle the Jaz
> drive separately?

A separate card, not necessarily old. Btw, using old controller with
recent chipsets does not appear like a good idea to me, especially with
PCI, even if specs says that this should work. The same remark applies to
SCSI.

> FWIW, I have the Jaz on a separate chain (the card has multiple chains for
> Ultra2, Ultra, and traditional SCSI-II). Also, the Jaz is unmounted when
> the problem occurs.

IIRC, the board uses a LVD to SE converter that allows to use SE device
and LVD device driven by a single SCSI initiator. I never tried such a
controller, but on controller that does not use LVD to SE converter you
must use *at most* 2 cables and terminate the BUS at each end and only at
each end. "End" mean the *extreme* end of the cable.
If you dismount the Jaz and the Jaz was not at one end of the BUS, you
have been fine, otherwise you just broke your BUS compliance.

> The LVD/Ultra2/80MBsec drive is on a chain all by itself. One internal
> cable from the card to the drive to the terminator.
>
> > > Every once and a while, I get something like the following in my log files:
>
> > You got 2 SCSI interrupts in the same second (UDC+PAR) that seem to have
> > occurred for a single cause. This is not impossible if the device
> > disconnected the BUS and the chip was reading the SCSI BUS, or if the
> > disconnect had been too hard. Btw, we get such kinds of error conditions
> > with not correctly set SCSI BUS.
>
> I apologize, but I am not sure what you mean by this. Can you explain
> further?
>
> Specifically, what do you mean by 'device disconnecting the SCSI bus'. I
> have disconnections "not allowed". Can it still happen anyway?

UDC means unexpected diconnection. That means that the device disconnected
from the BUS when the initiator didn't expect it to do so.

Disconnections not allowed means that the initiator does not grant the
device the privilege to disconnect the BUS with only partial data
transferred and to reconnect the BUS later for finishing the data
transfer. Such a disconnection must be achieved using rules that allow
the initiator to expect the BUS disconnect at a predictable time, i.e.:

- The target sends a SAVE DATA POINTER to the initiator
- The target sends a DISCONNECT message to the initiator
- The initiatior then expects the device to disconnect the BUS
after it has deasserted the SCSI ACK signal.

A device that disconnects the BUS (release the BSY and SEL signal) when
the initiator does not expect it to do so means that a severe error that
cannot be reported using the normal SCSI protocol error reporting rules
has been detected by the device. This one is an unexpected disconnection
and can happen at any time whether the device has been granted
disconnection priviledge for the transfer or not.

> Also, what do you mean by "disconnect being to hard"?

Normally, SCSI devices shall release all SCSI signal after the BSY and SEL
signal have been false for a bus settle delay = 400 ns.
I just imagined the device dropping all the signals without following this
rule or some very weird problem happening on the bus.

> Finally, what do you mean by a "not correctly set SCSI bus"? Do you mean,
> set as in the card is not seated properly? Or, not set properly in the SCSI
> BIOS parameters?
>
> > I suggest you the following:
>
> > 1 - Make sure that your SCSI BUS is, at least theorically, correctly
> > configured (cables characteristics and quality, terminator positions,
> > etc...). If you aren't sure enough, send me (us) the description of your
> > SCSI BUS (cables length, position of each terminator and devices).
>
> I have checked and rechecked this a number of times.
>
> > 2 - If you donnot have either old 810 rev. < 16 or 815 or 825 rev < 16 on
> > your system, give a try with the latest sym53c8xx-1.2a driver that has
> > been recently enhanced for SCSI error recovery. Changes haven't yet been
> > backported to stock ncr53c8xx driver.
>
> Where do I get this?

ftp://ftp.tux.org/pub/roudier/README
then
ftp://ftp.tux.org/pub/roudier/896/

> > 3 - Send me the messages printed by the driver at bootup using driver
> > verbose level 2. Boot command line : ncr53c8xx=verb:2
>
> I will do this the next time I reboot the machine.
>
> > 4 - Never use lspci command or cat /proc/pci/your_895_device under root
> > account with linux-2.1/2.2 since the reading of config space bytes 128 to
> > 256 will just read the whole IO register space of the chip and trigger
> > bunches of side effects that have every chance to kill your system.
>
> Hmm...Interesting. I will be sure not to do this.

But you can check it easily. :)

Regards,
Gérard.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:50    [W:0.093 / U:0.088 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site