From owner-freebsd-scsi@FreeBSD.ORG Thu Oct 14 21:50:16 2010 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F0E4D10656D1 for ; Thu, 14 Oct 2010 21:50:15 +0000 (UTC) (envelope-from kevin@your.org) Received: from mail.your.org (chi02.mail.your.org [204.9.55.23]) by mx1.freebsd.org (Postfix) with ESMTP id C11548FC12 for ; Thu, 14 Oct 2010 21:50:15 +0000 (UTC) Received: from mail.your.org (chi02.mail.your.org [204.9.55.23]) by mail.your.org (Postfix) with ESMTP id BD425F07027; Thu, 14 Oct 2010 21:50:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=your.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s= selector1; bh=MULHK7Yw0+zkjG2hzTaTvs5ES/8=; b=iFgNgvNcrixNDg8fZS LwbqVF4dsvacIdGXJ9Wluf4bR7nhH1ynoTOpLb35PanmRngdeb2JCOPi061w0LsO haeU597xBVQpJfX2aREjDYYAEj0dxWD8B8D5m3cfCUXnnQIDnpc8X31Hh37y6f7h qgb9rx624GpH/Ala+3DzTjtQ8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=your.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; q=dns; s= selector1; b=1NGfKhwzXv/ffE94fGCfOPRKyH+VpUv62UjTh7KlTLnlPhBCh9v +NRuxHHfDUItfRGx6OT7lVx/AlYzpposvhDzn1ks6mqybbrqJl97klg9NZH8epGt ODVpWLfwsRiuYO6LoJH+vg8DNe1+JdKgj/nRCayO7EkmjEO3MAjf+Hs4= Received: from vpn177.ord02.your.org (vpn177.ord02.your.org [204.9.55.177]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.your.org (Postfix) with ESMTPSA id 308A2F0701C; Thu, 14 Oct 2010 21:50:14 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Kevin Day In-Reply-To: <9B56BE59-38FD-46EF-89C3-0A5035BE324C@samsco.org> Date: Thu, 14 Oct 2010 16:50:13 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <911A3B60-559B-471E-90B2-3D7754AC8D17@your.org> <9B56BE59-38FD-46EF-89C3-0A5035BE324C@samsco.org> To: Scott Long X-Mailer: Apple Mail (2.1078) Cc: freebsd-scsi@freebsd.org Subject: Re: mfi "unexpected sense" when using mfip/smartctl 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, 14 Oct 2010 21:50:16 -0000 On Oct 12, 2010, at 8:02 PM, Scott Long wrote: > On Oct 12, 2010, at 3:15 PM, Kevin Day wrote: >>=20 >> Hey, SCSI people! >>=20 >> I'm trying to use smartctl (from smartmontools) with an mfi card. I = can kldload mfip, and use smartctl to access SMART data on the member = drives fine. The problem is that each time I do so, I get: >>=20 >> mfi0: 13501 (340232122s/0x0002/info) - Unexpected sense: PD = 05(e0x04/s0) Path 50030480006deec4, CDB: 85 06 2c 00 da 00 00 00 00 00 = 4f 00 c2 00 b0 00, Sense: c/6d/00 >>=20 >> I'm assuming this shows up because the RAID controller isn't = expecting the reply to the command that smartctl is sending behind it's = back. >>=20 >> If so, this is pretty harmless, but it looks very very similar to = what happens when there's a serious problem with a drive. Is there a way = this could be muted, or is this indicating that something is actually = not working right?=20 >>=20 >=20 > You're exactly right about the controller firmware seeing a side = effect of running smartctl. You can cross-ref the sense codes at = http://www.t10.org/lists/asc-num.txt if you're interested. The reported = code of "c/6d/00" doesn't make any sense to me, but I guess it's ok. As = long as it's not kicking the array into failover mode, it's harmless. I = think that there is an official way of doing SMART in-band with the = controller that avoids this confusion, I'll look into it. It likely = means that smartctl will need learn how to talk to the /dev/mfi0 = interface, or mfiutil will need to learn about SMART commands. Neither = option is terribly easy. >=20 > Scott I've been looking at this a bit more... Smartctl on Linux uses a special ioctl to talk to the controller like a = passthrough device, which makes the code path nearly identical to = FreeBSD+smartctl+mfip. But on Linux, it's not generating any log entries = on the controller. (I even checked to make sure they weren't somehow not = being printed on the console, but they really aren't being generated at = the card itself).=20 I don't see a great deal of differences between what Linux is doing and = what happens here, but I also agree that the sense code being reported = doesn't make sense. I'm kinda wondering if somehow we're not sending the = controller a bad/additional/unhappy passthrough frame, which is making = it send an additional command to the drive. Smartctl seems mostly = functional, but requires turning off some sanity checks that aren't = necessary on identical hardware/drives under Linux to make it work. Before I dig much deeper, do you have any wild guesses? :) -- Kevin