From owner-freebsd-scsi@FreeBSD.ORG Thu Nov 16 17:38:44 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 74E8416A4A7; Thu, 16 Nov 2006 17:38:44 +0000 (UTC) (envelope-from ken@nargothrond.kdm.org) Received: from nargothrond.kdm.org (nargothrond.kdm.org [70.56.43.81]) by mx1.FreeBSD.org (Postfix) with ESMTP id E2B1743D5D; Thu, 16 Nov 2006 17:38:43 +0000 (GMT) (envelope-from ken@nargothrond.kdm.org) Received: from nargothrond.kdm.org (localhost [127.0.0.1]) by nargothrond.kdm.org (8.13.6/8.13.6) with ESMTP id kAGHcgde066352; Thu, 16 Nov 2006 10:38:42 -0700 (MST) (envelope-from ken@nargothrond.kdm.org) Received: (from ken@localhost) by nargothrond.kdm.org (8.13.6/8.13.6/Submit) id kAGHcgWQ066351; Thu, 16 Nov 2006 10:38:42 -0700 (MST) (envelope-from ken) Date: Thu, 16 Nov 2006 10:38:42 -0700 From: "Kenneth D. Merry" To: Matthew Jacob Message-ID: <20061116173842.GB64023@nargothrond.kdm.org> References: <20061115211433.R8053@ns1.feral.com> <20061116061158.GA37070@nargothrond.kdm.org> <7579f7fb0611160836t655c8100j31e300a37c0cc9dc@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7579f7fb0611160836t655c8100j31e300a37c0cc9dc@mail.gmail.com> User-Agent: Mutt/1.4.2i X-Virus-Scanned: ClamAV 0.88.1/2200/Thu Nov 16 07:10:16 2006 on nargothrond.kdm.org X-Virus-Status: Clean Cc: freebsd-scsi@freebsd.org, mjacob@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 List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2006 17:38:44 -0000 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...) Ken -- Kenneth Merry ken@kdm.org