On Thu, 22 Jul 1999, Gerard Roudier wrote:
> chip (390) hacked for it to work with SYM53C8XX series. Just hoping that
> their drivers for commercial O/Ses are not made of the same recipe.
I am happy to think they are :)
I most of the time write target code for embedded controllers (e.g.
RAID SCSI-to-SCSI boards, mostly, based on 80296SA and diversly
sourced SCSI chips, such as Qlogic FAS209/366U, Fujitsu MB86606,
and others). I do preliminary testing on Linux (read: fire test),
and then I do test on many other plateforms, such as Solaris, IRIX,
MacOS (!), MS-* (NT, 9x), OS/2, and sometimes even AmigaOS or
embedded variants.
I can't comment for Tekram, but the Adaptec 7870 drivers for MS-*'NT are
very interesting: if the target violates the protocol in some way (in my
case it was my target saying CHECK CONDITION on an INQUIRY with LUN bits
set, ie where proper comportment was to return invalid LUN in the INQUIRY
data, ie 0x7F if I remember well as type), the OS or the driver usually
crashes in some bizarre way.
In that case, MS-*'NT (or the Adaptec driver) was simply randomly
switching off sync parameters for that device, causing a hang at the
next fast data I/O. I reported the problem to Microsoft and Adaptec,
without any answer since 1997. Of course, this problem is not to happen
in normal operation, except if you include broken target code :)
Linux drivers for ncr53c8xx and aic7xxx are *much more* stable in those
areas. Even, in a special bizarre case where my target was sending a
few more bytes was diagnosed properly by your ncr53c8xx driver (data
overrun) and recovered. NT and OS/2 were just hanging up randomly,
or crashing, depending on the transfer direction.
The Linux QLOGICISP driver was just hanging: in that case the Linux driver
can't do a lot, since most of the protocol is handled in the firmware. I
reported a few of those problems to QLOGIC, and they fixed them after some
time. I think the firmware which is bundled with the new qlogicisp driver
(e.g. on http://www.feral.com) has most of those fixes built-in, e.g.
restore pointer fixes, etc.
Note that there are Linux SCSI drivers which are of very low quality, or
which do not interact well with the new SCSI recovery mechanism: for
example a bug was fixed in between 2.0.27 and 2.0.35, bug which would
never initiate real reset retry (a bad value in a case, if I remember).
Fixing that bug has now rendered the aha1542 driver unreliable if you
get any I/O error on a disk drive (causes infinite retries).
[ if that interests you, diff scsi.c and look for a changing case, I can
find it again if this is important ]
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
