G�rard,
Thanks for the reply,
Last night I took a further look at some of this stuff.
What I was hoping for was that you'd use the inquiry data (byte 2
back from a normal inquiry command contains ISO Vers, ECMA Version and ANSI
Appr version) to figure out what sort of device it was (Scsi 1/2/3), and
then change byte 1 of the defective CDB's accordingly. This wouldn't break
existing functionality, and would be a bit more spec compliant. From what I
remember, byte 1 bits 7,6,5 are only actually reserved in Scsi 3, Scsi 2
being a bit of a half way house. I'm sure there must be other products out
there that strictly adhere to the specification, and hence won't work. The
main worry being that the committee can reclaim those bits at any point now
they are reserved, and that would really hose your driver. Let me know what
you think.
I've not tried any other drivers other than the Symbios (the main
reason I wanted to use the Symbios is the residual byte reporting, the
aic7xxx driver - my other option - doesn't support this), but I suspect
they'll operate in a similar fashion as you say.
I had a talk with my firmware buddies, and the solution we
eventually implemented was to ignore those LUN bits for Inquiry and Request
Sense commands only, all other commands will check condition as before. I
disagree about ignoring reserved fields, not checking reserved fields is
definitely a bad way to go from the firmware's perspective. As you
recommended, it's probably prudent to deviate from the spec in order to be a
good bus device. I did have to bribe the firmware kiddies after you
"over-picky device" comments though ;-) As they said, we end up debating
this sort of thing all the time. Now that we've made this change, a vendor
could fail our drive for compliance, so we end up in no mans land.
Kindest Regards,
|\
|/ave
-----Original Message-----
From: G�rard Roudier [mailto:[EMAIL PROTECTED]]
Sent: Thursday, July 13, 2000 9:06 PM
To: Falkinder, David
Cc: [EMAIL PROTECTED]
Subject: Re: Feature in ncr53c8xx/sym53c8xx driver
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]
