On Fri, 14 Jul 2000, Falkinder, David wrote:
> 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
I am been told by private email about some that actually do. :-)
> 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 mostly agree on your statements, but I donnot want the low-level driver
to hack any CDB that it hasn't set-up by it-self.
> 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.
Most (all?) drivers that perform auto-sense will.
> 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
May-be this should be proposed to the comittee. It will for sure be
refused but comments may be helpfull.
> disagree about ignoring reserved fields, not checking reserved fields is
> definitely a bad way to go from the firmware's perspective. As you
IMO, if all parts (hardware and software) in a machine enforced all
implementations of everything thing to conform to specifications, the
machine will not even boot.
> 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.
My remark was in the context of all existing SCSI access methods. I just
wanted to point out the reality problem. Obviously, I agree that SCSI
access methods have to be fixed in order to conform to specifications.
By the way, you probably donnot ignore that numerous other situations
exist where,
- compliant A does not work
while,
- not-compliant B does (seem to) work.
For example, let A be a PCI device+driver pair that enforces PCI parity
checking and B not doing so. Btw, for this kind of compliance, color me
"over-picky". :-)
Regards,
G�rard.
>
> 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]
>
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
