[9184] in linux-scsi channel archive
Feature in ncr53c8xx/sym53c8xx driver
daemon@ATHENA.MIT.EDU (Falkinder, David)
Thu Jul 13 10:51:23 2000
Message-ID: <13037D3EF290D211B95F00A0C9EBECC4AF71E3@tungsten.bri.hp.com>
From: "Falkinder, David" <davidf@bri.hp.com>
To: linux-scsi@vger.rutgers.edu
Cc: =?iso-8859-1?Q?=27G=E9rard_Roudier=27?= <groudier@club-internet.fr>
Date: Thu, 13 Jul 2000 15:47:57 +0100
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Greetings,
I think I may have a handle on some of the problems that have been
seen with the sym53c8xx and ncr53c8xx driver.
It may be that this has been fixed already, I'm only playing with a
standard SuSe 6.4 kernel, but it would be nice to know.
It's to do with the race condition. I think other people have been
seeing it with SCSI 2 & 3 devices. It appears to have been put down to "bad
termination" in some cases. I hooked up a SCSI analyser and here's what I
found.
327 391_940 Bus Free
328 3_400 Arb
329 2_210 Arbwin 7
330 0_800 +Select 7,1
331 5_305 +Sel/Resel End
332 4_310 +MsgOut 81 Identify
333 1_467_400 CMD - Tst Unit Rdy
00 20 00 00 00 00
<- SCSI-1 type command (LUN in byte 1), byte 1 is a reserved field in
SCSI 2 & 3 spec.
334 2_360 Status 02 Check Condition <-
Check condition (Illegal field in CDB type thing).
335 3_275 MsgIn 00 Cmd Complete
336 28_830 Bus Free
337 3_510 Arb
338 2_200 Arbwin 7
339 0_800 +Select 7,1
340 7_745 +Sel/Resel End
341 11_030 +MsgOut 81 Identify
342 1_108_070 CMD - Req Sense <-
When we go to read the sense, again we issue it in SCSI 1 format.
03 20 00 00 10 00
343 2_400 Status 02 Check Condition <-
Again we see a check condition for an illegal field, and wander around the
loop again !!!
344 3_245 MsgIn 00 Cmd Complete
345 49_600 Bus Free
346 3_300 Arb
347 2_200 Arbwin 7
348 0_810 +Select 7,1
349 7_755 +Sel/Resel End
350 11_020 +MsgOut 81 Identify
351 1_380_590 CMD - Req Sense
03 20 00 00 10 00
352 2_500 Status 02 Check Condition
353 4_765 MsgIn 00 Cmd Complete
354 28_350 Bus Free
Nb. (Upper three bits of byte 1 are the LUN, so 0x20 is 00100000b i.e.
actually LUN 1)
So boiling it down, the core of the problem is that for SCSI 1 the LUN is
set in byte 1 (zero indexed CDB) for the Test Unit Ready and Request Sense
commands, where as these are reserved fields in SCSI 2 and 3 specs. A check
condition causes a request sense, which provides an infinite loop.
This will be pretty device specific as I know for example HP's DDS-4 units
ignore the use of the LUN bits in byte 1.
We're getting into the realms of IMHO here, (I've not taken a look at the
code), but I think the device type (SCSI 1/2/3) should already be known from
the inquiry data, and hence the driver should be able to send the "correct"
cdb (for either SCSI-1 or SCSI-2/3 devices).
Comments ?
Kindest Regards,
|\
|/ave
David Falkinder (R&D Engineer) Tel: +44 (0)117 922 9849
Computer Peripherals Bristol. Fax: +44 (0)117 923 6091
HEWLETT PACKARD LTD.
Filton Road
Stoke Gifford
Bristol Email: davidf@bri.hp.com
BS12 6QZ
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.rutgers.edu
