amusing stumble for the 6 to 10 byte checking code

mjacob at mjacob at
Thu Nov 16 18:09:12 UTC 2006

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!

More information about the freebsd-scsi mailing list