From owner-freebsd-stable@FreeBSD.ORG Mon Dec 17 22:10:54 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1DB72E1F for ; Mon, 17 Dec 2012 22:10:54 +0000 (UTC) (envelope-from jim.harris@gmail.com) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by mx1.freebsd.org (Postfix) with ESMTP id 94EE68FC0C for ; Mon, 17 Dec 2012 22:10:53 +0000 (UTC) Received: by mail-wi0-f170.google.com with SMTP id hq7so2495283wib.1 for ; Mon, 17 Dec 2012 14:10:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/6+xTqMyjeI9vho81orj4eVBfwmrC/z8UqqwNr3UFVg=; b=Nq+DUPs9HPfunrxZrEAuR8U7mRIURWgg/5UGKGEKpRI+B2o/1S63uvJus6E1gVYwfy JFl5L+T0WWX/AEStCb5n/pW8E95vYY6qTPxsQ8QcGgVIZ60PQSjfLl3R1+OLUP65em2j b+cjO9fanpxDT5Y5qLUKzJDYl81KHsdyBQYBydu4Z4COPIf3MnWaX8593LWuzGZ48KSC unE5drqV+7jtES8I+O2Qlm2rpaYdhjD8ICadk34uFyDjnTxCqXjF4GtN9lV/jqM6iLn+ xep7Xgph02OfU4zKZHqxSGrIjQNLJaBhW2YSjLIyPScL31BI0abqq/ic+jf9X32w/IuL pTHg== MIME-Version: 1.0 Received: by 10.194.20.231 with SMTP id q7mr19926092wje.44.1355782252303; Mon, 17 Dec 2012 14:10:52 -0800 (PST) Received: by 10.217.57.4 with HTTP; Mon, 17 Dec 2012 14:10:52 -0800 (PST) In-Reply-To: <50CF925C.5040106@digiware.nl> References: <50CEFAC5.8000002@digiware.nl> <572946ED30FA47C69D6DCDD511CF6EB2@multiplay.co.uk> <50CF47A5.4090008@digiware.nl> <50CF925C.5040106@digiware.nl> Date: Mon, 17 Dec 2012 15:10:52 -0700 Message-ID: Subject: Re: Strange CAM errors From: Jim Harris To: Willem Jan Withagen Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Stable Users X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 22:10:54 -0000 On Mon, Dec 17, 2012 at 2:45 PM, Willem Jan Withagen wrote: > On 17-12-2012 20:16, Jim Harris wrote:> > > The timeouts are occurring on inquiry commands to non-zero LUNs. > > arcmsr(4) is returning CAM_SEL_TIMEOUT instead of CAM_DEV_NOT_THERE for > > inquiry commands to this device and LUN > 0. CAM_DEV_NOT_THERE is > > preferred to remove these types of warnings, and similar patches have > > gone into for other SCSI drivers recently. > > > > Can you try this patch? > > > > Index: sys/dev/arcmsr/arcmsr.c > > =================================================================== > > --- sys/dev/arcmsr/arcmsr.c (revision 244190) > > +++ sys/dev/arcmsr/arcmsr.c (working copy) > > @@ -2439,7 +2439,7 @@ > > char *buffer=pccb->csio.data_ptr; > > > > if (pccb->ccb_h.target_lun) { > > - pccb->ccb_h.status |= CAM_SEL_TIMEOUT; > > + pccb->ccb_h.status |= CAM_DEV_NOT_THERE; > > xpt_done(pccb); > > return; > > } > > > > Hi Jim, > > The noise has gone down by a factor of 5, now I get: > > (probe6:arcmsr0:0:16:1): INQUIRY. CDB: 12 20 0 0 24 0 > (probe6:arcmsr0:0:16:1): CAM status: Unable to terminate I/O CCB request > (probe6:arcmsr0:0:16:1): Error 5, Unretryable error > (probe6:arcmsr0:0:16:2): INQUIRY. CDB: 12 40 0 0 24 0 > > Which is defined in sys/cam/cam.c .... > as CAM_UA_TERMIO, but that error is nowhere set in the arcmsr code.... > > There is something out of sync on your system. I just noticed this, but your original error messages were showing "Command timeout" (CAM_CMD_TIMEOUT) even though the driver was returning CAM_SEL_TIMEOUT. Now in this case, driver is returning CAM_DEV_NOT_THERE, but CAM is printing error message for CAM_UA_TERMIO. In both cases, driver is returning value X, but cam is interpreting it as X+1. So CAM and arcmsr(4) seem to have a different idea of the values of the cam_status enumeration. Can you provide details on your build environment? Are you building arcmsr as a loadable module or do you specify "device arcmsr" in your kernel config to link it statically? I'm suspecting loadable module, although I have no idea how these values would get out of sync since this enumeration hasn't changed in probably 10+ years. -Jim