From owner-freebsd-bugs@FreeBSD.ORG Tue Apr 3 21:00:05 2012 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DA4A41065670 for ; Tue, 3 Apr 2012 21:00:05 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A543D8FC14 for ; Tue, 3 Apr 2012 21:00:05 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q33L05vv063370 for ; Tue, 3 Apr 2012 21:00:05 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q33L05YS063360; Tue, 3 Apr 2012 21:00:05 GMT (envelope-from gnats) Resent-Date: Tue, 3 Apr 2012 21:00:05 GMT Resent-Message-Id: <201204032100.q33L05YS063360@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-bugs@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Garrett Wollman Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 105F41065678 for ; Tue, 3 Apr 2012 20:55:21 +0000 (UTC) (envelope-from wollman@zfsnfs.csail.mit.edu) Received: from zfsnfs.csail.mit.edu (zfsnfs.csail.mit.edu [128.30.113.117]) by mx1.freebsd.org (Postfix) with ESMTP id C65508FC0C for ; Tue, 3 Apr 2012 20:55:20 +0000 (UTC) Received: from zfsnfs.csail.mit.edu (localhost [127.0.0.1]) by zfsnfs.csail.mit.edu (8.14.5/8.14.5) with ESMTP id q33KdvQu072533 for ; Tue, 3 Apr 2012 16:39:57 -0400 (EDT) (envelope-from wollman@zfsnfs.csail.mit.edu) Received: (from wollman@localhost) by zfsnfs.csail.mit.edu (8.14.5/8.14.5/Submit) id q33Kdvpr072532; Tue, 3 Apr 2012 16:39:57 -0400 (EDT) (envelope-from wollman) Message-Id: <201204032039.q33Kdvpr072532@zfsnfs.csail.mit.edu> Date: Tue, 3 Apr 2012 16:39:57 -0400 (EDT) From: Garrett Wollman To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 Cc: Subject: kern/166621: "CAM status: Unconditionally Re-queue Request" not handled X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Garrett Wollman List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 21:00:06 -0000 >Number: 166621 >Category: kern >Synopsis: "CAM status: Unconditionally Re-queue Request" not handled >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Apr 03 21:00:05 UTC 2012 >Closed-Date: >Last-Modified: >Originator: Garrett Wollman >Release: FreeBSD 9.0-RELEASE amd64 >Organization: MIT Computer Science and Artificial Intelligence Laboratory >Environment: System: FreeBSD zfsnfs.csail.mit.edu 9.0-RELEASE FreeBSD 9.0-RELEASE #3 r232145M: Sun Feb 26 20:00:10 EST 2012 wollman@zfsnfs.csail.mit.edu:/usr/obj/usr/src/sys/ZFSNFS amd64 Using backported version of LSI-supported mps driver from 9-STABLE. This incorporates the following changes from FreeBSD 9-STABLE: 230920, 231679, 231690, 231940 >Description: smartctl/smartd sometimes fail when talking to a busy SAS drive as a result of a temporary error. I'm not sure whether the retry should be happening in the kernel or in the SMART library, hence I'm filing this as a kernel bug. smartctl error report looks like this: smartctl 5.42 2011-10-20 r3458 [FreeBSD 9.0-RELEASE amd64] (local build) Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net Vendor: SEAGATE Product: ST32000444SS Revision: 0006 User Capacity: 2,000,398,934,016 bytes [2.00 TB] Logical block size: 512 bytes (pass8:mps0:0:21:0): MODE SENSE(6). CDB: 1a 0 1c 0 40 0 (pass8:mps0:0:21:0): CAM status: Unconditionally Re-queue Request >How-To-Repeat: Try to run "smartctl -a" or smartd on a really busy SAS drive connected to a SAS port expander connected to a 16-port LSI eSAS HBA. Sometimes it works, sometimes it fails. >Fix: Either the kernel should retry the request, or smartctl/smartd should. If the view of the SAS experts is that the application should respond appropriately, I'll file a bug against smartmontools. >Release-Note: >Audit-Trail: >Unformatted: >> Terminate command early due to bad response to IEC mode page A mandatory SMART command failed: exiting. To continue, add one or more '-T permissive' options.