From owner-freebsd-scsi@FreeBSD.ORG Thu Nov 16 18:09:12 2006 Return-Path: X-Original-To: freebsd-scsi@freebsd.org Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 524D816A417 for ; Thu, 16 Nov 2006 18:09:12 +0000 (UTC) (envelope-from mjacob@freebsd.org) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id C5DF443D9D for ; Thu, 16 Nov 2006 18:08:52 +0000 (GMT) (envelope-from mjacob@freebsd.org) Received: from ns1.feral.com (localhost [127.0.0.1]) by ns1.feral.com (8.13.8/8.13.8) with ESMTP id kAGI8g2s010013; Thu, 16 Nov 2006 10:08:52 -0800 (PST) (envelope-from mjacob@freebsd.org) Received: from localhost (mjacob@localhost) by ns1.feral.com (8.13.8/8.13.8/Submit) with ESMTP id kAGI8gDw010010; Thu, 16 Nov 2006 10:08:42 -0800 (PST) (envelope-from mjacob@freebsd.org) X-Authentication-Warning: ns1.feral.com: mjacob owned process doing -bs Date: Thu, 16 Nov 2006 10:08:42 -0800 (PST) From: mjacob@freebsd.org X-X-Sender: mjacob@ns1.feral.com To: "Kenneth D. Merry" In-Reply-To: <20061116173842.GB64023@nargothrond.kdm.org> Message-ID: <20061116100713.D9739@ns1.feral.com> References: <20061115211433.R8053@ns1.feral.com> <20061116061158.GA37070@nargothrond.kdm.org> <7579f7fb0611160836t655c8100j31e300a37c0cc9dc@mail.gmail.com> <20061116173842.GB64023@nargothrond.kdm.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-scsi@freebsd.org Subject: Re: amusing stumble for the 6 to 10 byte checking code X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mjacob@freebsd.org List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2006 18:09:12 -0000 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!