amusing stumble for the 6 to 10 byte checking code

[mjacob at freebsd.org]

On Thu, 16 Nov 2006, Kenneth D. Merry wrote:

> On Thu, Nov 16, 2006 at 08:36:15 -0800, Matthew Jacob wrote:
>>> That shouldn't have happened in response to a unit attention.  It should
>>> only happen if the SIM comes back with CAM_REQ_INVALID, or if the target
>>> comes back with an illegal request sense code.  So there may have been
>>> another intervening error that caused the switchover.
>>
>> Yeah- but where?
>
> I dunno.  I just took a quick look through CAM and the ISP driver for
> CAM_REQ_INVALID, and didn't see any obvious place that would return
> CAM_REQ_INVALID for a 6 byte write...
>
> Computers are causal, though, so I'm sure there's a reason in there
> *somewhere*...
>
>>>> (da0:isp1:0:0:0): WRITE(10). CDB: 2a 0 0 8 68 90 0 0 80 0
>>>> (da0:isp1:0:0:0): CAM Status: SCSI Status Error
>>>> (da0:isp1:0:0:0): SCSI Status: Check Condition
>>>> (da0:isp1:0:0:0): ILLEGAL REQUEST asc:24,0
>>>> (da0:isp1:0:0:0): Invalid field in CDB
>>>> (da0:isp1:0:0:0): Unretryable error
>>>
>>> Hmm.  Illegal field, and not invalid command operation code?  That's odd.
>>> What kind of drive is this?  The CDB looks valid at first glance...
>>>
>>
>> Yeah, this is what's puzzling me. This is a normal FC drive. Puzzled...
>
> Yeah, definitely a weird error.  I'd never expect a SCSI drive to reject a
> normal 10 byte write like that.  There are no weird flags in the CDB, and
> the lba and length don't seem out of range at all...  (Unless you've got a
> 200MB hard FC hard drive...)

Hmm- that might be lcue. It might have been one of my 50MB test virtual 
luns which *might* have had a bad label. That gives me a clue of where 
to go look for at least the second error- thanks!