Good spot.
But, by the way, not only the [ncr|sym]53c8xx drivers do format the auto
REQUEST SENSE command with the LUN << 5 value in byte 1.
Indeed the fix you suggest works in theory, but who knows if it will
not break some other devices that would expect the LUN << 5 but would
claim different from SCSI-1.
As it is required to set to zero reserved bits, it is also usual to not
check reserved bit against zero, especially if they address ancient
standards. Give all existing drivers that actually set LUN << 5 in
byte 1, the part that is victimized here is rather the too much picky
device than the sym53c8xx driver.
This looks to me like a device suicide.;-)
Given that you seem to work in the company that supply such over-picky
device I would suggest you to also inform your colleagues that developped
the firmware of this device about their bad decision of having been
so paranoid about those reserved bits.
Anyway, thanks a lot for the report.
G�rard.
On Thu, 13 Jul 2000, Falkinder, David wrote:
> 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: [EMAIL PROTECTED]
> BS12 6QZ
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to [EMAIL PROTECTED]
>
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
