[5226] in linux-scsi channel archive
Re: DC390/AM53C974 SCSI driver 2.0c3 (more fixes)
daemon@ATHENA.MIT.EDU (Kurt Garloff)
Sat Nov 28 07:03:06 1998
Date: Sat, 28 Nov 1998 12:54:49 +0100
From: Kurt Garloff <garloff@kg1.ping.de>
To: Andreas Haumer <andreas@xss.co.at>,
Attila Bilgic <bilgic@hft.e-technik.uni-dortmund.de>,
Bert Hutzler <hutzler@Fh-Worms.DE>,
Christian Dietsch <root@christian.wupper.de>,
Dieter Schlueter <Dieter.Schlueter@bild.dd.shuttle.de>,
=?iso-8859-1?Q?Engstr=F6m=2C_Fredrik?= <chimay@myself.com>,
Jacek Czerwinski <klik@rubikon.net.pl>,
Linux SCSI list <linux-scsi@vger.rutgers.edu>,
Philip Giang <philip@tekram.com.tw>,
Georges Giralt <georges.giralt@alcatel.fr>, georges.giralt@hol.fr,
Robert Fendt <fendt@student.physik.uni-dortmund.de>,
Stefan Becker <Stefan.Becker@post.rwth-aachen.de>,
Frank Bess <Frank_Bess@crow.bmc.com>,
"M. Kleinsorge" <Martin.Kleinsorge@post.rwth-aachen.de>
Mail-Followup-To: Andreas Haumer <andreas@xss.co.at>,
Attila Bilgic <bilgic@hft.e-technik.uni-dortmund.de>,
Bert Hutzler <hutzler@Fh-Worms.DE>,
Christian Dietsch <root@christian.wupper.de>,
Dieter Schlueter <Dieter.Schlueter@bild.dd.shuttle.de>,
=?iso-8859-1?Q?Engstr=F6m=2C_Fredrik?= <chimay@myself.com>,
Jacek Czerwinski <klik@rubikon.net.pl>,
Linux SCSI list <linux-scsi@vger.rutgers.edu>,
Philip Giang <philip@tekram.com.tw>,
Georges Giralt <georges.giralt@alcatel.fr>, georges.giralt@hol.fr,
Robert Fendt <fendt@student.physik.uni-dortmund.de>,
Stefan Becker <Stefan.Becker@post.rwth-aachen.de>,
Frank Bess <Frank_Bess@crow.bmc.com>,
"M. Kleinsorge" <Martin.Kleinsorge@post.rwth-aachen.de>
In-Reply-To: <19981128010317.B822@kg1.ping.de>; from Kurt Garloff on Sat, Nov 28, 1998 at 01:03:17AM +0100
Hi DC390/AM53C974 users,
It seems that the AM53C974 does read messages byte by byte, in contradiction
to the documentation. It's sort of obviuos, as the AM53C974 has no means to
know, how many bytes the messages have ... (unless it decodes them).
So, I think, version 2.0c2 will refuse to accept multibyte messages anbd
therefore fail with TagQueueing and Synchronous transfers. I changed the
behaviour of 2.0c3 to still accept multibyte messages.
The bad thing is, that it requires an IRQ for every message byte and as such
is rather slow. This isn't that bad for the SDTR message, as it occurs
seldomly, but I can imagine a slowdown for Tagged Command Queueing, which
uses two byte messages.
I implemented a polling mechansim similar to the other AM53C974 driver's, but
SMP-safe, which is disabled by default, as the code is ugly. (It has to be.)
Please, if you successfully tested 2.0c3, recompile with -DDC390_POLL_IRQ to
enable the polling mechanism for the multibyte messages and get a little
performance enhancement and tell me whether it works.
(If you remember polling is bad and slow, you're not wrong. Defining
DC390_POLL_IRQ does not result in the driver using polling for normal
communication, however. It just avoid generating an IRQ in a situation,
where we exactly know another byte is there. This won't fail unless you
device is very very very buggy. And then you will see a Message: "DC390:
Deadlock in poll_irq!!" and the driver will try to continue.)
Also for the target initiated SDTR, I implemented a more elegant solution
(thanks to Gerard for clearifying the SCSI-2 draft to me): We don't reject
it any longer, but we send a corrected SDTR back.
The driver 2.0c3 can be found on student, as usual:
ftp://student.physik.uni-dortmund.de/pub/linux/kernel/dc390/
I'm looking forward to get reports.
--
Kurt Garloff <K.Garloff@ping.de> (Dortmund, FRG)
PGP key on http://student.physik.uni-dortmund.de/homepages/garloff
The second clause "open source code of derivative works" has been the
most controversial (and, potentially the most successful) aspect of
CopyLeft licensing. -- Halloween Document
P.S.: If someone wants to discuss the SMP-safety of the other AM53C974 driver
or wants me to fix it, please go ahead.
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.rutgers.edu
