[4895] in linux-scsi channel archive
Re: Testers for DC390-120t2 (AM53C974) SCSI driver wanted
daemon@ATHENA.MIT.EDU (ishikawa)
Thu Oct 15 01:57:29 1998
Date: Thu, 15 Oct 1998 03:51:14 +0900
From: ishikawa <ishikawa@yk.rim.or.jp>
To: Kurt Garloff <garloff@kg1.ping.de>
CC: linux-scsi@vger.rutgers.edu
Hello Garloff-san,
I have tested the latest 1.20t4 on my PC.
I tested it against the one hard drive and the Nakamichi CD changer unit.
Sorry it tookme so long to respond to your call for testing.
I had been busy and my Nakamichi changer was hooked up to a different
PC.
After about an hour or so testing based on previously prepared test scripts,
the driver seems to be just fine.
A few things to note:
1. A minor typo.
cat /proc/scsi/tmscsim/* shows that
the 1.20 t4 version driver still has the message banner "1.20t3".
Apparently, tmscsim.c was not updated yet.
% egrep t[34] tmscsim.c
* 1.20t398/10/06 KG Minor changes ... *
* 1.20t498/10/10 KG In timeout loops (DataIn_0, ..Out_0): *
SPRINTF("Driver Version 1.20t3, 1998/10/06\n");
However, when the driver is inserted the module name is shown correctly
with 1.20t4. (This string is in dc390.h.).
2. You might want to mention that the single lun patch mentioned in README
file is definitely in 2.0.36 : the pre-patches for 2.0.36 include it now.
Yes, the README mentioned 2.0.35, but some readers will wonder
if 2.0.36 fixes this problem and we might want to answer the question in the README
file.
Happy Hacking,
Chiaki Ishikawa
PS: Do you remember the bug triggered by
dd if=/dev/srX of=/dev/null &
dd if=/dev/srY of=/dev/null
where srX, and srY refer to the different CD media in the Nakamichi changer
device? The system got hung.
The bug apparently is in the higher-level SCSI mid-level code.
I verified the existence of the bug using BusLogic driver on a different PC.
(This is why the CD changer was hooked on a different PC.)
I have tried to figure out what the possible fix can be, and find that
previously posted Waltham's patch is only a partial solution. I think we needed to
initialize a variable in allocate_device() loop when we modify the
routine a la Waltham's patch.
However, even with my further patch, my PC still got hung.
The only time the test succeeded, er, PC didn't hung after the test script
was issued, the system got hung again after I hit ^C to stop the test script
halfway through its operation.
There is one observation: if we insert "sleep 1" between the two dd commands
above, the system seems to work OK!
When I asked him after reading
Waltham's message that his patch worked on his computer,
it turned out that he typed the commands from shell manually.
So there was a long enough pause between two dd commands whereas
my tests were done using pre-written shell scripts and so the
dd commands were issued in a quick succession and my PC got hung.
Given this observation, I think there is a timing or improper exclusion of
certain critical regions in the scsi mid-level code and tried to see if I can
find the cause.
But I gave up: the lack of updated design document hurts here.
It is true RTFM rules, but
the source code and its comment didn't explain fully about the `implicit'
assumptions about timing/exclusion, etc. adequately to my uninitiated eyes.
Since 2.1.xxx development is in full swing, maybe it is not a good time for
the subtle bug to be debugged right now by the experts. This is unfortunate.
Kurt Garloff wrote:
>
> On Tue, Oct 06, 1998 at 10:28:25PM +0200, Kurt Garloff wrote:
> > Hi there,
> >
> > if you got an AM53C974 based PCI SCSI host adapter, e.g. Tekram DC390(T) or
> > DawiControl 2974, then please test my latest driver: dc390-120t3
> > You can find it on
> > ftp://student.physik.uni-dortmund.de/pub/linux/kernel/dc390/
>
> A bug has been found and fixed. I you met
> DC390: DataIn_0: DAM timed out. 0 bytes remain.
> then you should upgrade to 1.20t4.
>
> Driver is on its usual place.
>
> Still looking forward to seeing more test results.
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.rutgers.edu
