From owner-freebsd-scsi@FreeBSD.ORG Mon Jan 20 11:06:52 2014 Return-Path: Delivered-To: freebsd-scsi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EAA93AC4 for ; Mon, 20 Jan 2014 11:06:52 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D60691D7D for ; Mon, 20 Jan 2014 11:06:52 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id s0KB6qfN088475 for ; Mon, 20 Jan 2014 11:06:52 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id s0KB6q09088471 for freebsd-scsi@FreeBSD.org; Mon, 20 Jan 2014 11:06:52 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 20 Jan 2014 11:06:52 GMT Message-Id: <201401201106.s0KB6q09088471@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-scsi@FreeBSD.org Subject: Current problem reports assigned to freebsd-scsi@FreeBSD.org X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 11:06:53 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/184059 scsi [mps] mps SCSI driver causes FreeBSD to hang during bo o kern/179932 scsi [ciss] ciss i/o stall problem with HP Bl Gen8 (and HP o kern/178795 scsi [mps] MSI for mps driver doesn't work under vmware o kern/165982 scsi [mpt] mpt instability, drive resets, and losses on Fre o kern/165740 scsi [cam] SCSI code must drain callbacks before free f kern/162256 scsi [mpt] QUEUE FULL EVENT and 'mpt_cam_event: 0x0' o docs/151336 scsi Missing documentation of scsi_ and ata_ functions in c o kern/148083 scsi [aac] Strange device reporting o kern/144648 scsi [aac] Strange values of speed and bus width in dmesg o kern/142351 scsi [mpt] LSILogic driver performance problems o kern/134488 scsi [mpt] MPT SCSI driver probes max. 8 LUNs per device o kern/130621 scsi [mpt] tranfer rate is inscrutable slow when use lsi213 f kern/129602 scsi [ahd] ahd(4) gets confused and wedges SCSI bus f kern/123674 scsi [ahc] ahc driver dumping o sparc/121676 scsi [iscsi] iscontrol do not connect iscsi-target on sparc 15 problems total. From owner-freebsd-scsi@FreeBSD.ORG Tue Jan 21 00:28:47 2014 Return-Path: Delivered-To: scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E3078AC4 for ; Tue, 21 Jan 2014 00:28:47 +0000 (UTC) Received: from smtp.infotech.no (smtp.infotech.no [82.134.31.41]) by mx1.freebsd.org (Postfix) with ESMTP id A0B211CEB for ; Tue, 21 Jan 2014 00:28:47 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.infotech.no (Postfix) with ESMTP id 52FBB2041C3 for ; Tue, 21 Jan 2014 01:22:20 +0100 (CET) X-Virus-Scanned: by amavisd-new-2.6.6 (20110518) (Debian) at infotech.no Received: from smtp.infotech.no ([127.0.0.1]) by localhost (smtp.infotech.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pKe5mVz9XXTz for ; Tue, 21 Jan 2014 01:22:20 +0100 (CET) Received: from [10.7.0.30] (unknown [10.7.0.30]) by smtp.infotech.no (Postfix) with ESMTPA id D20672041B2 for ; Tue, 21 Jan 2014 01:22:19 +0100 (CET) Message-ID: <52DDBDB4.2020408@interlog.com> Date: Mon, 20 Jan 2014 19:22:12 -0500 From: Douglas Gilbert User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: scsi@freebsd.org Subject: upgrade to 10.0: lost root fs on LSI 9300-4i Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: dgilbert@interlog.com List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 00:28:47 -0000 So I tried to upgrade from 9.2 to 10.0-release expecting it to find my LSI 9300-4i (SAS-3) HBA that was holding my root file system in 9.2 . Nope, a dismal failure: List of GEOM managed disk devices: mountroot> Sorry FreeBSD, that is just very disappointing. Any suggestions short of a complete re-install? Doug Gilbert From owner-freebsd-scsi@FreeBSD.ORG Tue Jan 21 04:11:09 2014 Return-Path: Delivered-To: scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7A5EDED0 for ; Tue, 21 Jan 2014 04:11:09 +0000 (UTC) Received: from nm2-vm5.bullet.mail.ne1.yahoo.com (nm2-vm5.bullet.mail.ne1.yahoo.com [98.138.91.224]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id ED1591DAD for ; Tue, 21 Jan 2014 04:11:08 +0000 (UTC) Received: from [98.138.100.113] by nm2.bullet.mail.ne1.yahoo.com with NNFMP; 21 Jan 2014 04:08:45 -0000 Received: from [98.138.226.59] by tm104.bullet.mail.ne1.yahoo.com with NNFMP; 21 Jan 2014 04:08:45 -0000 Received: from [127.0.0.1] by smtp210.mail.ne1.yahoo.com with NNFMP; 21 Jan 2014 04:08:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1390277325; bh=foaqOlZGj1tkCm0ufPn/HDYI+4Y7fq2xbyGIhPsmT+s=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Subject:From:Reply-To:To:Cc:In-Reply-To:References:Content-Type:Date:Message-ID:Mime-Version:X-Mailer:Content-Transfer-Encoding; b=oI6oXT+/DTxTiXmlaKqatzXN3XauuokVc2oIF0df+GFtvgSKOv4AuW5VPSL04zLFbSuQKzfkIU3Q228/FBouLwryLZXR9idg8jgvI0UE63Jk9T8UV5y9crbEHCcmx3aCnSbTEbNcay69fQ0Ou7bvFpKcycwD8nYv61+BNfe664w= X-Yahoo-Newman-Id: 87559.20940.bm@smtp210.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: h3NFxjAVM1kEqDcUxDPex0U71gBp_VXVUCMlhjV9m6g7h15 NFfbP75Eo7hVqi65ZnN5HM.iAqb.UYYzFYb_ZpCdAhScv_4AYpd.jMGzqJY6 wO5p2Rl5GoJa6.GkjdiuojE__o0DG6UpVPoKAJd_Avo5MJ2ICoVUTZdz9uDA QF0llpWAnJUjKzoxcD0d8NpNgf_yu.pX8iA3j9Hn.y8WJ3yhQpLbpmqok40q sQGRQVbObDykUU5E4zGF3IN4whk_i77hmN1kNTBBYTu4fGoxsleHxLRRFQ9q KSjX6NtT6FHSHJMKWNwDknQaU.W4noBMT2pp7AZGIry11L80_WbDJcQgoQge PcIBdNb9stqdRbo4yMecFWrtC0KTWQNE2QWWd1KspoaCl12l7AJFZOJLW5kV u56CToPjt2WiPiMrUkmiUOSy7NLkZd9nD2IELDjTTW4nZh47z0RrkXQYLTOq gcSWCmnkduXVgYY8rw_n2QF26UDU85uqU8fk_KB4e0g0t.u5kHJYEHUBrHvF 3ysaca_R6Am9v95y8FDeLOr9pWg2D_AC2MXJNtPHp.DGniQJlE0SGKiKbOA- - X-Yahoo-SMTP: u5BKR6OswBC_iZJVfGRoMkTIpc8pEA4- X-Rocket-Received: from [192.168.1.138] (sean_bruno@24.23.220.111 with plain [98.139.211.125]) by smtp210.mail.ne1.yahoo.com with SMTP; 20 Jan 2014 20:08:44 -0800 PST Subject: Re: upgrade to 10.0: lost root fs on LSI 9300-4i From: Sean Bruno To: dgilbert@interlog.com In-Reply-To: <52DDBDB4.2020408@interlog.com> References: <52DDBDB4.2020408@interlog.com> Content-Type: text/plain; charset="us-ascii" Date: Mon, 20 Jan 2014 20:08:42 -0800 Message-ID: <1390277322.86352.0.camel@powernoodle.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: scsi@freebsd.org X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: sbruno@freebsd.org List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 04:11:09 -0000 On Mon, 2014-01-20 at 19:22 -0500, Douglas Gilbert wrote: > So I tried to upgrade from 9.2 to 10.0-release expecting > it to find my LSI 9300-4i (SAS-3) HBA that was holding > my root file system in 9.2 . > > Nope, a dismal failure: > > List of GEOM managed disk devices: > > > mountroot> > > > Sorry FreeBSD, that is just very disappointing. > > Any suggestions short of a complete re-install? > > Doug Gilbert It sort of looks like a device enumeration issue. Can you post your dmesg output from boot? sean From owner-freebsd-scsi@FreeBSD.ORG Tue Jan 21 05:04:34 2014 Return-Path: Delivered-To: scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 20B20873; Tue, 21 Jan 2014 05:04:34 +0000 (UTC) Received: from smtp.infotech.no (smtp.infotech.no [82.134.31.41]) by mx1.freebsd.org (Postfix) with ESMTP id D14951116; Tue, 21 Jan 2014 05:04:33 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.infotech.no (Postfix) with ESMTP id 966122041C3; Tue, 21 Jan 2014 06:04:31 +0100 (CET) X-Virus-Scanned: by amavisd-new-2.6.6 (20110518) (Debian) at infotech.no Received: from smtp.infotech.no ([127.0.0.1]) by localhost (smtp.infotech.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YMx9VLd4NuAI; Tue, 21 Jan 2014 06:04:31 +0100 (CET) Received: from [10.7.0.30] (unknown [10.7.0.30]) by smtp.infotech.no (Postfix) with ESMTPA id EC712204160; Tue, 21 Jan 2014 06:04:30 +0100 (CET) Message-ID: <52DDFFD8.8020600@interlog.com> Date: Tue, 21 Jan 2014 00:04:24 -0500 From: Douglas Gilbert User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: sbruno@freebsd.org Subject: Re: upgrade to 10.0: lost root fs on LSI 9300-4i References: <52DDBDB4.2020408@interlog.com> <1390277322.86352.0.camel@powernoodle.corp.yahoo.com> In-Reply-To: <1390277322.86352.0.camel@powernoodle.corp.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: scsi@freebsd.org X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: dgilbert@interlog.com List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 05:04:34 -0000 On 14-01-20 11:08 PM, Sean Bruno wrote: > On Mon, 2014-01-20 at 19:22 -0500, Douglas Gilbert wrote: >> So I tried to upgrade from 9.2 to 10.0-release expecting >> it to find my LSI 9300-4i (SAS-3) HBA that was holding >> my root file system in 9.2 . >> >> Nope, a dismal failure: >> >> List of GEOM managed disk devices: >> >> >> mountroot> >> >> >> Sorry FreeBSD, that is just very disappointing. >> >> Any suggestions short of a complete re-install? >> >> Doug Gilbert > > It sort of looks like a device enumeration issue. Can you post your > dmesg output from boot? Hi, It sort of looks like a driver enumeration issue, as is there isn't one for the LSI 9300 series SAS-3 HBAs. That family has been on sale for 7 months and Linux has had a driver (mpt3sas) for it for 15 to 18 months. LSI themselves did most of the work and something is available here for FreeBSD: http://www.lsi.com/products/host-bus-adapters/pages/lsi-sas-9300-4i4e.aspx (latest for FreeBSD 9.0) And you would think freebsd-update might notice that it was leading a user over a cliff when the driver supporting the HBA and attached disk including the root fs had no support in the target version (10.0 in the case). My solution was to regress to a LSI SAS-2 HBA which is supported by the mps driver. Do I still need to call that driver out explicitly in /boot/loader.conf in 10.0 as was done in the 9.* series? Doug Gilbert From owner-freebsd-scsi@FreeBSD.ORG Tue Jan 21 08:11:54 2014 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A5DEA9B for ; Tue, 21 Jan 2014 08:11:54 +0000 (UTC) Received: from mail.red.mailbank.com.au (mail.mailbank.com.au [202.172.112.4]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2AF4B1F3B for ; Tue, 21 Jan 2014 08:11:52 +0000 (UTC) Received: from GREEN by mail.mailbank.com.au (RTG Mail Server) with ESMTP id HJW61131 for ; Tue, 21 Jan 2014 19:01:31 +1100 MIME-Version: 1.0 From: "Aurora Global Logistics" Sender: "Aurora Global Logistics" To: "freebsd-scsi@freebsd.org" Date: Tue, 21 Jan 2014 19:01:31 +1100 Subject: Aurora International Yacht Logistics - E-Newsletter Message-ID: <201401210131.580.8374115@red.mailbank.com.au> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Yacht-Transport@auroralogistics.com List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 08:11:54 -0000 KioqIElNUE9SVEFOVCBOT1RFICoqKiANCklmIHlvdSBjYW4gc2VlIHRoaXMgdGV4dCwgeW91IGFy ZSBub3QgdXNpbmcgSFRNTCBlbmFibGVkIGVtYWlsIHNvZnR3YXJlLiANCg0KDQpZb3UgY2FuIHZp ZXcgdGhpcyBlLW1haWwgb25saW5lIGF0IA0KaHR0cDovL21haWxiYW5rLmNvbS5hdS9PbmxpbmUv P0I9MTQwNDk0JkJLPTBBQjZFQkI4RTIwQjQNCg0KKioqKioqIA0K From owner-freebsd-scsi@FreeBSD.ORG Tue Jan 21 08:50:07 2014 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 780DA5A1 for ; Tue, 21 Jan 2014 08:50:07 +0000 (UTC) Received: from mail-oa0-x247.google.com (mail-oa0-x247.google.com [IPv6:2607:f8b0:4003:c02::247]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4134812E5 for ; Tue, 21 Jan 2014 08:50:07 +0000 (UTC) Received: by mail-oa0-f71.google.com with SMTP id g12so11785274oah.10 for ; Tue, 21 Jan 2014 00:50:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:message-id:date:subject:from:to:content-type; bh=B+N9STzNmR+3aOfFbXxfOZxtlYd3TDRV3ozuk/hnP0w=; b=q4wVspcu4Wa1tSmH+kRpU++7SB6jRIeA82rSZCb3iBPusyzfwsKzYEXYuUD7pGUits MTQ9gEJ7Gv87C2IDTo1AmEXvyZ6V7/L+MVKaTUkXGziNVb+zl2awHvGVB7do062T4s+C pfIxQ9ctOqMUdSDSEGvrOq5jegkk42OHwtvTnDpdXNU1qHwPT9PlG0boK763onCmPyH8 YrmbzbqTg6JOX1d/MXkcB6RHLrLkyo1HJjDBaegZDlGm6jj0nhF86nx8pU4x5H5ogvpq mj9VsjO7oggvEBA8MxGQFriuTOMdeRdL9hE+TNeJ1p4YiDeWti3yWN0TENO7rZ64wCC5 GZiQ== MIME-Version: 1.0 X-Received: by 10.182.236.74 with SMTP id us10mr8519217obc.36.1390294206551; Tue, 21 Jan 2014 00:50:06 -0800 (PST) Message-ID: <001a11c329d2509d7e04f0771861@google.com> Date: Tue, 21 Jan 2014 08:50:06 +0000 Subject: www.freebsd.org From: Anna Garcia To: freebsd-scsi@freebsd.org Content-Type: text/plain; charset=windows-1252; format=flowed; delsp=yes Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 08:50:07 -0000 SGksDQoNCkkganVzdCB3YW50ZWQgdG8gc2VuZCB5b3UgYSBxdWljayBub3RlLiBXaXRoIGEgZmV3 IHNpbXBsZSBjaGFuZ2VzIHRvIG1ha2UNCnlvdXIgc2l0ZSBtb3JlIFNFTy1mcmllbmRseSBJkm0g c3VyZSB5b3UgY2FuIGNvbnZlcnQgbW9yZSB2aXNpdG9ycyBpbnRvDQpsZWFkcyBhbmQgZ2V0IGl0 IHBsYWNlZCBoaWdoZXIgaW4gdGhlIG9yZ2FuaWMgc2VhcmNoIHJlc3VsdHMsIGZvciBrZXl3b3Jk cw0KdGhhdCBtYXR0ZXIgdG8geW91IHRoZSBtb3N0Lg0KDQpXZSBhcmUgYW4gQXVzdHJhbGlhbiBi YXNlZCBjb21wYW55IHdpdGggYSBncmVhdCBpbi1ob3VzZSB0ZWNobmljYWwgdGVhbSB3aG8NCnJl YWxseSBrbm93IHRoZWlyIHN0dWZmIGFib3V0IHNlYXJjaCBlbmdpbmUgb3B0aW1pemF0aW9uLg0K DQpXb3VsZCB5b3UgbGlrZSBhIGJpdCBtb3JlIGluZm9ybWF0aW9uIGFib3V0IGhvdyB0byBnaXZl IHlvdXIgd2Vic2l0ZSBhDQpib29zdCB3aXRoIGJldHRlciBTRU8/DQoNCkJlc3QgcmVnYXJkcywN Cg0KQW5uYSBHYXJjaWENClNFTy9XRUIgU3BlY2lhbGlzdA0KDQpbaW1hZ2U6IExpbmtlZEluXSBb aW1hZ2U6IEZhY2Vib29rXSBbaW1hZ2U6IFR3aXR0ZXJdIFtpbWFnZTogU2t5cGVdDQogICAgICAg ICAgICAgUyAgIEUgIE8gICAgICAgICAgICAqU2VhcmNoIEVuZ2luZSBPcHRpbWl6YXRpb24qDQoN CldlIHJlc3BlY3QgeW91ciBwcml2YWN5IGFuZCB3YW50IHRvIG1ha2Ugc3VyZSB5b3UgYXJlIGF3 YXJlIG9mIGEgZmV3DQp0aGluZ3MuIEJ5IHJlcGx5aW5nIHRvIHRoaXMgZW1haWwsIHlvdSBhdXRo b3JpemUgb3VyIEF1c3RyYWxpYW4gYWZmaWxpYXRlcw0KdGhhdCBjYW4gaGVscCB3aXRoIHlvdXIg cHJvamVjdCB0byBjYWxsIHlvdSBhdCB0aGUgbnVtYmVyIHlvdSBwcm92aWRlZCwgYW5kDQp5b3Ug dW5kZXJzdGFuZCB0aGF0IHRoZXkgbWF5IHVzZSBhdXRvbWF0ZWQgcGhvbmUgdGVjaG5vbG9neSB0 byBjYWxsIHlvdS4gQXQNCm5vIHRpbWUgYXJlIHlvdSByZXF1aXJlZCB0byBtYWtlIGEgcHVyY2hh c2UuDQo= From owner-freebsd-scsi@FreeBSD.ORG Thu Jan 23 12:50:37 2014 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A5672BBE for ; Thu, 23 Jan 2014 12:50:37 +0000 (UTC) Received: from mail-bk0-x22d.google.com (mail-bk0-x22d.google.com [IPv6:2a00:1450:4008:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2AAFD1A40 for ; Thu, 23 Jan 2014 12:50:37 +0000 (UTC) Received: by mail-bk0-f45.google.com with SMTP id v16so341988bkz.32 for ; Thu, 23 Jan 2014 04:50:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=o9CpHSOsAc/bwVL3zepKWeBmQVx+O9SJjt/HovjyQQ0=; b=pbOmvpSZfyT0qD6B3mY3oz5MEWe4q3OvzEFz/yQ+hShB+hfwaE9t6V2jggvTMRRWVn s++jgM2oq1z7DjV1d694yqZitEqz/tC/ZujUqJz9bL9Tbhp8eoM1cwhDfpuIJaS1WSeh GwoifuqAKPhLLrXtnnusvQvF3HMMRwEMOt80RnJowCvn1sJFVGIIc7YMqEEls7zVC/hE 4/8yCgZ6Zv0VgyI/PvJHoBzqTZrBvU8NVuMsaxizuOo7F9irHWECEnV1S3BTwki1N1Mi MbUkn0H1V89pMlTakQ1cq3aZp2Pq+8rLQRu7DmBY8WSlwiTtLzrN55lADGWBVh640nQK 3v5w== X-Received: by 10.205.12.133 with SMTP id pi5mr1003381bkb.54.1390481435486; Thu, 23 Jan 2014 04:50:35 -0800 (PST) Received: from ?IPv6:2a02:6b8::408:542c:b96f:fb92:fbb0? ([2a02:6b8:0:408:542c:b96f:fb92:fbb0]) by mx.google.com with ESMTPSA id tf11sm9027288bkb.17.2014.01.23.04.50.34 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 23 Jan 2014 04:50:34 -0800 (PST) From: Dmitry Sivachenko Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Strange messages from ses(4) Message-Id: Date: Thu, 23 Jan 2014 16:50:33 +0400 To: freebsd-scsi@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) X-Mailer: Apple Mail (2.1827) X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 12:50:37 -0000 Hello! I have a machine running stable/10 and mfi1: = controller with two disk bundles connected to it (15 disks each). =46rom time to time the following messages appear: Jan 23 07:19:19 agata kernel: ses0: pass1: Element descriptor: '000' Jan 23 07:19:19 agata kernel: ses0: pass1: SAS Device Slot Element: 1 = Phys at Slot 0, Not All Phys Jan 23 07:19:19 agata kernel: ses0: phy 0: SATA device Jan 23 07:19:19 agata kernel: ses0: phy 0: parent 5003048000366f7f addr = 5003048000366f48 Jan 23 07:19:19 agata kernel: ses0: pass2: Element descriptor: '001' Jan 23 07:19:19 agata kernel: ses0: pass2: SAS Device Slot Element: 1 = Phys at Slot 1, Not All Phys Jan 23 07:19:19 agata kernel: ses0: phy 0: SATA device Jan 23 07:19:19 agata kernel: ses0: phy 0: parent 5003048000366f7f addr = 5003048000366f49 Jan 23 07:19:19 agata kernel: ses0: pass3: Element descriptor: '002' Jan 23 07:19:19 agata kernel: ses0: pass3: SAS Device Slot Element: 1 = Phys at Slot 2, Not All Phys Jan 23 07:19:19 agata kernel: ses0: phy 0: SATA device Jan 23 07:19:19 agata kernel: ses0: phy 0: parent 5003048000366f7f addr = 5003048000366f4a Jan 23 07:19:19 agata kernel: ses0: pass4: Element descriptor: '003' Jan 23 07:19:19 agata kernel: ses0: pass4: SAS Device Slot Element: 1 = Phys at Slot 3, Not All Phys Jan 23 07:19:19 agata kernel: ses0: phy 0: SATA device Jan 23 07:19:19 agata kernel: ses0: phy 0: parent 5003048000366f7f addr = 5003048000366f4b Jan 23 07:19:19 agata kernel: ses0: pass5: Element descriptor: '004' Jan 23 07:19:19 agata kernel: ses0: pass5: SAS Device Slot Element: 1 = Phys at Slot 4, Not All Phys Jan 23 07:19:19 agata kernel: ses0: phy 0: SATA device Jan 23 07:19:19 agata kernel: ses0: phy 0: parent 5003048000366f7f addr = 5003048000366f4c Jan 23 07:19:19 agata kernel: ses0: pass6: Element descriptor: '005' Jan 23 07:19:19 agata kernel: ses0: pass6: SAS Device Slot Element: 1 = Phys at Slot 5, Not All Phys Jan 23 07:19:19 agata kernel: ses0: phy 0: SATA device Jan 23 07:19:19 agata kernel: ses0: phy 0: parent 5003048000366f7f addr = 5003048000366f4d Jan 23 07:19:19 agata kernel: ses0: pass7: Element descriptor: '006' Jan 23 07:19:19 agata kernel: ses0: pass7: SAS Device Slot Element: 1 = Phys at Slot 6, Not All Phys Jan 23 07:19:19 agata kernel: ses0: phy 0: SATA device Jan 23 07:19:19 agata kernel: ses0: phy 0: parent 5003048000366f7f addr = 5003048000366f4e Jan 23 07:19:19 agata kernel: ses0: pass8: Element descriptor: '007' Jan 23 07:19:19 agata kernel: ses0: pass8: SAS Device Slot Element: 1 = Phys at Slot 7, Not All Phys Jan 23 07:19:19 agata kernel: ses0: phy 0: SATA device Jan 23 07:19:19 agata kernel: ses0: phy 0: parent 5003048000366f7f addr = 5003048000366f4f Jan 23 07:19:19 agata kernel: ses0: pass9: Element descriptor: '008' Jan 23 07:19:19 agata kernel: ses0: pass9: SAS Device Slot Element: 1 = Phys at Slot 8, Not All Phys Jan 23 07:19:19 agata kernel: ses0: phy 0: SATA device Jan 23 07:19:19 agata kernel: ses0: phy 0: parent 5003048000366f7f addr = 5003048000366f50 Jan 23 07:19:19 agata kernel: ses0: pass10: Element descriptor: '009' Jan 23 07:19:19 agata kernel: ses0: pass10: SAS Device Slot Element: 1 = Phys at Slot 9, Not All Phys Jan 23 07:19:19 agata kernel: ses0: phy 0: SATA device Jan 23 07:19:19 agata kernel: ses0: phy 0: parent 5003048000366f7f addr = 5003048000366f51 Jan 23 07:19:19 agata kernel: ses0: pass11: Element descriptor: '010' Jan 23 07:19:19 agata kernel: ses0: pass11: SAS Device Slot Element: 1 = Phys at Slot 10, Not All Phys Jan 23 07:19:19 agata kernel: ses0: phy 0: SATA device Jan 23 07:19:19 agata kernel: ses0: phy 0: parent 5003048000366f7f addr = 5003048000366f52 Jan 23 07:19:19 agata kernel: ses0: pass12: Element descriptor: '011' Jan 23 07:19:19 agata kernel: ses0: pass12: SAS Device Slot Element: 1 = Phys at Slot 11, Not All Phys Jan 23 07:19:19 agata kernel: ses0: phy 0: SATA device Jan 23 07:19:19 agata kernel: ses0: phy 0: parent 5003048000366f7f addr = 5003048000366f53 Jan 23 07:19:19 agata kernel: ses0: pass14: Element descriptor: '012' Jan 23 07:19:19 agata kernel: ses0: pass14: SAS Device Slot Element: 1 = Phys at Slot 12, Not All Phys Jan 23 07:19:19 agata kernel: ses0: phy 0: SATA device Jan 23 07:19:19 agata kernel: ses0: phy 0: parent 5003048000366f7f addr = 5003048000366f54 Jan 23 07:19:19 agata kernel: ses0: pass13: Element descriptor: '013' Jan 23 07:19:19 agata kernel: ses0: pass13: SAS Device Slot Element: 1 = Phys at Slot 13, Not All Phys Jan 23 07:19:19 agata kernel: ses0: phy 0: SATA device Jan 23 07:19:19 agata kernel: ses0: phy 0: parent 5003048000366f7f addr = 5003048000366f55 Jan 23 07:19:19 agata kernel: ses0: pass15: Element descriptor: '014' Jan 23 07:19:19 agata kernel: ses0: pass15: SAS Device Slot Element: 1 = Phys at Slot 14, Not All Phys Jan 23 07:19:19 agata kernel: ses0: phy 0: SATA device Jan 23 07:19:19 agata kernel: ses0: phy 0: parent 5003048000366f7f addr = 5003048000366f56 Jan 23 07:19:19 agata kernel: ses0: pass16: Element descriptor: '015' Jan 23 07:19:19 agata kernel: ses0: pass16: SAS Device Slot Element: 1 = Phys at Slot 15, Not All Phys Jan 23 07:19:19 agata kernel: ses0: phy 0: SATA device Jan 23 07:19:19 agata kernel: ses0: phy 0: parent 5003048000366f7f addr = 5003048000366f57 What does it mean? Thanks in advance.= From owner-freebsd-scsi@FreeBSD.ORG Thu Jan 23 16:20:14 2014 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 36F83F8B for ; Thu, 23 Jan 2014 16:20:14 +0000 (UTC) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BA0431F42 for ; Thu, 23 Jan 2014 16:20:13 +0000 (UTC) Received: by mail-wg0-f50.google.com with SMTP id l18so1758559wgh.5 for ; Thu, 23 Jan 2014 08:20:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=qGTxX4mmFCwtyciM6+mh6UhEj9G0mOxS1UbTIdzybck=; b=bfWfFCEQet3+4HZTj1bOx7QquTtp2mvfcHJ/NfEfjTGu3zfH9mVOp3bdvdEvQbf5uz 3/fCp50copiwqH3Q7d7MaPivm4bEJCNph35CSsy7h3JCVGU3JV7XiJmEByU7YbJnkxi6 siTZfSPpYKB3rOxsz5gNn1qMpulN1NV/dVqRH3LRu483lQlEuGDyuHwf8+HzKm+BOPTl 1LwTLEj2IMKciRpEsQvaVyCpQ/yDom9d4aFb5+5tOf+rdokKMHpi7l6zU9c6Rqr36Zw+ X0QqVRk2reZxvCNcb4w+/h12alpqAY1UIO0WByECWZ4XdrXhSbliQIAoOu54PcqBE1Wi fUwg== MIME-Version: 1.0 X-Received: by 10.195.12.164 with SMTP id er4mr201212wjd.92.1390494011042; Thu, 23 Jan 2014 08:20:11 -0800 (PST) Sender: asomers@gmail.com Received: by 10.194.22.35 with HTTP; Thu, 23 Jan 2014 08:20:10 -0800 (PST) In-Reply-To: References: Date: Thu, 23 Jan 2014 09:20:10 -0700 X-Google-Sender-Auth: U7B9A1Ex8UyTguXFF3Z0ND-7JXQ Message-ID: Subject: Re: Strange messages from ses(4) From: Alan Somers To: Dmitry Sivachenko Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-scsi@freebsd.org X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 16:20:14 -0000 On Thu, Jan 23, 2014 at 5:50 AM, Dmitry Sivachenko wrote: > Hello! > > I have a machine running stable/10 and mfi1: controller with two disk bundles connected to it > (15 disks each). > > From time to time the following messages appear: > > Jan 23 07:19:19 agata kernel: ses0: pass1: Element descriptor: '000' > Jan 23 07:19:19 agata kernel: ses0: pass1: SAS Device Slot Element: 1 Phys at Slot 0, Not All Phys > Jan 23 07:19:19 agata kernel: ses0: phy 0: SATA device > Jan 23 07:19:19 agata kernel: ses0: phy 0: parent 5003048000366f7f addr 5003048000366f48 > Jan 23 07:19:19 agata kernel: ses0: pass2: Element descriptor: '001' > Jan 23 07:19:19 agata kernel: ses0: pass2: SAS Device Slot Element: 1 Phys at Slot 1, Not All Phys > Jan 23 07:19:19 agata kernel: ses0: phy 0: SATA device > Jan 23 07:19:19 agata kernel: ses0: phy 0: parent 5003048000366f7f addr 5003048000366f49 > Jan 23 07:19:19 agata kernel: ses0: pass3: Element descriptor: '002' > Jan 23 07:19:19 agata kernel: ses0: pass3: SAS Device Slot Element: 1 Phys at Slot 2, Not All Phys > Jan 23 07:19:19 agata kernel: ses0: phy 0: SATA device > Jan 23 07:19:19 agata kernel: ses0: phy 0: parent 5003048000366f7f addr 5003048000366f4a > Jan 23 07:19:19 agata kernel: ses0: pass4: Element descriptor: '003' > Jan 23 07:19:19 agata kernel: ses0: pass4: SAS Device Slot Element: 1 Phys at Slot 3, Not All Phys > Jan 23 07:19:19 agata kernel: ses0: phy 0: SATA device > Jan 23 07:19:19 agata kernel: ses0: phy 0: parent 5003048000366f7f addr 5003048000366f4b > Jan 23 07:19:19 agata kernel: ses0: pass5: Element descriptor: '004' > Jan 23 07:19:19 agata kernel: ses0: pass5: SAS Device Slot Element: 1 Phys at Slot 4, Not All Phys > Jan 23 07:19:19 agata kernel: ses0: phy 0: SATA device > Jan 23 07:19:19 agata kernel: ses0: phy 0: parent 5003048000366f7f addr 5003048000366f4c > Jan 23 07:19:19 agata kernel: ses0: pass6: Element descriptor: '005' > Jan 23 07:19:19 agata kernel: ses0: pass6: SAS Device Slot Element: 1 Phys at Slot 5, Not All Phys > Jan 23 07:19:19 agata kernel: ses0: phy 0: SATA device > Jan 23 07:19:19 agata kernel: ses0: phy 0: parent 5003048000366f7f addr 5003048000366f4d > Jan 23 07:19:19 agata kernel: ses0: pass7: Element descriptor: '006' > Jan 23 07:19:19 agata kernel: ses0: pass7: SAS Device Slot Element: 1 Phys at Slot 6, Not All Phys > Jan 23 07:19:19 agata kernel: ses0: phy 0: SATA device > Jan 23 07:19:19 agata kernel: ses0: phy 0: parent 5003048000366f7f addr 5003048000366f4e > Jan 23 07:19:19 agata kernel: ses0: pass8: Element descriptor: '007' > Jan 23 07:19:19 agata kernel: ses0: pass8: SAS Device Slot Element: 1 Phys at Slot 7, Not All Phys > Jan 23 07:19:19 agata kernel: ses0: phy 0: SATA device > Jan 23 07:19:19 agata kernel: ses0: phy 0: parent 5003048000366f7f addr 5003048000366f4f > Jan 23 07:19:19 agata kernel: ses0: pass9: Element descriptor: '008' > Jan 23 07:19:19 agata kernel: ses0: pass9: SAS Device Slot Element: 1 Phys at Slot 8, Not All Phys > Jan 23 07:19:19 agata kernel: ses0: phy 0: SATA device > Jan 23 07:19:19 agata kernel: ses0: phy 0: parent 5003048000366f7f addr 5003048000366f50 > Jan 23 07:19:19 agata kernel: ses0: pass10: Element descriptor: '009' > Jan 23 07:19:19 agata kernel: ses0: pass10: SAS Device Slot Element: 1 Phys at Slot 9, Not All Phys > Jan 23 07:19:19 agata kernel: ses0: phy 0: SATA device > Jan 23 07:19:19 agata kernel: ses0: phy 0: parent 5003048000366f7f addr 5003048000366f51 > Jan 23 07:19:19 agata kernel: ses0: pass11: Element descriptor: '010' > Jan 23 07:19:19 agata kernel: ses0: pass11: SAS Device Slot Element: 1 Phys at Slot 10, Not All Phys > Jan 23 07:19:19 agata kernel: ses0: phy 0: SATA device > Jan 23 07:19:19 agata kernel: ses0: phy 0: parent 5003048000366f7f addr 5003048000366f52 > Jan 23 07:19:19 agata kernel: ses0: pass12: Element descriptor: '011' > Jan 23 07:19:19 agata kernel: ses0: pass12: SAS Device Slot Element: 1 Phys at Slot 11, Not All Phys > Jan 23 07:19:19 agata kernel: ses0: phy 0: SATA device > Jan 23 07:19:19 agata kernel: ses0: phy 0: parent 5003048000366f7f addr 5003048000366f53 > Jan 23 07:19:19 agata kernel: ses0: pass14: Element descriptor: '012' > Jan 23 07:19:19 agata kernel: ses0: pass14: SAS Device Slot Element: 1 Phys at Slot 12, Not All Phys > Jan 23 07:19:19 agata kernel: ses0: phy 0: SATA device > Jan 23 07:19:19 agata kernel: ses0: phy 0: parent 5003048000366f7f addr 5003048000366f54 > Jan 23 07:19:19 agata kernel: ses0: pass13: Element descriptor: '013' > Jan 23 07:19:19 agata kernel: ses0: pass13: SAS Device Slot Element: 1 Phys at Slot 13, Not All Phys > Jan 23 07:19:19 agata kernel: ses0: phy 0: SATA device > Jan 23 07:19:19 agata kernel: ses0: phy 0: parent 5003048000366f7f addr 5003048000366f55 > Jan 23 07:19:19 agata kernel: ses0: pass15: Element descriptor: '014' > Jan 23 07:19:19 agata kernel: ses0: pass15: SAS Device Slot Element: 1 Phys at Slot 14, Not All Phys > Jan 23 07:19:19 agata kernel: ses0: phy 0: SATA device > Jan 23 07:19:19 agata kernel: ses0: phy 0: parent 5003048000366f7f addr 5003048000366f56 > Jan 23 07:19:19 agata kernel: ses0: pass16: Element descriptor: '015' > Jan 23 07:19:19 agata kernel: ses0: pass16: SAS Device Slot Element: 1 Phys at Slot 15, Not All Phys > Jan 23 07:19:19 agata kernel: ses0: phy 0: SATA device > Jan 23 07:19:19 agata kernel: ses0: phy 0: parent 5003048000366f7f addr 5003048000366f57 > > > What does it mean? The ses(4) driver prints that message whenever it sees the "NOT ALL PHYS" bit in the SAS protocol specific descriptor in the Additional Element Status page. According to the SES-3 spec, revision 6: The NUMBER OF PHY DESCRIPTORS field indicates how many phy descriptors are in the phy descriptor list. A NOT ALL PHYS bit set to one indicates that all phys in the SAS device or SATA device may or may not be described. A NOT ALL PHYS bit set to zero indicates that all phys in the SAS device or SATA device are described. NOTE 6 - The NOT ALL PHYS bit may be set to one for SAS devices with multiple ports, where the enclosure services process only has access to information about the phys in one of the ports (e.g., in the same SAS domain as the enclosure services process It sounds pretty trivial. I would pay it no mind. BTW, a good tool to help debug issues like this is "sg_ses" from the sg3_utils port. -Alan > > Thanks in advance. > _______________________________________________ > freebsd-scsi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-scsi > To unsubscribe, send any mail to "freebsd-scsi-unsubscribe@freebsd.org" From owner-freebsd-scsi@FreeBSD.ORG Fri Jan 24 19:08:33 2014 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 57DFFED8; Fri, 24 Jan 2014 19:08:33 +0000 (UTC) Received: from mail.ambrisko.com (mail.ambrisko.com [70.91.206.90]) by mx1.freebsd.org (Postfix) with ESMTP id 313271F86; Fri, 24 Jan 2014 19:08:32 +0000 (UTC) X-Ambrisko-Me: Yes Received: from server2.ambrisko.com (HELO internal.ambrisko.com) ([192.168.1.2]) by ironport.ambrisko.com with ESMTP; 24 Jan 2014 11:13:01 -0800 Received: from ambrisko.com (localhost [127.0.0.1]) by internal.ambrisko.com (8.14.4/8.14.4) with ESMTP id s0OJ8W3e038417; Fri, 24 Jan 2014 11:08:32 -0800 (PST) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.14.4/8.14.4/Submit) id s0OJ8WFP038416; Fri, 24 Jan 2014 11:08:32 -0800 (PST) (envelope-from ambrisko) Date: Fri, 24 Jan 2014 11:08:32 -0800 From: Doug Ambrisko To: Mark Johnston Subject: Re: mfi(4) support for MegaRAID Fury cards Message-ID: <20140124190832.GB28724@ambrisko.com> References: <20131227220455.GA6027@charmander.home> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20131227220455.GA6027@charmander.home> User-Agent: Mutt/1.4.2.3i Cc: freebsd-scsi@freebsd.org, ambrisko@freebsd.org X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 19:08:33 -0000 On Fri, Dec 27, 2013 at 05:04:55PM -0500, Mark Johnston wrote: | Hello, | | The patch here adds mfi(4) support for my LSI 9341-4i controller, which | has device ID 0x5f: | | http://people.freebsd.org/~markj/patches/mfi_fury.diff | | This diff was mostly obtained by going through the mrsas(4) code | specific to Invader (DID 0x5d) and Fury (DID 0x5f) controllers. The main | change is to add an end-of-list marker to scatter-gather DMA lists | before handing them to the firmware. Without this, large writes to an | mfi(4) volume result in a firmware crash loop, and the system needs to | be reset. The diff adds code for both Invader and Fury cards, as this is | what's done in mrsas(4); I haven't tested with an Invader card though, | as I don't have access to one. With this patch, I'm able to boot FreeBSD | 8.2 off of a RAID 1 volume on my 9341-4i. | | Would anyone be able to review or test this patch? I'm particularly | interested if anyone could try it out with an Invader or Fury card | (there shouldn't be any differences in driver behaviour with other | cards). The patch looks good. I can test it out on a Invader card that I have. I don't have a Fury card. I was holding off waiting to see how we should resolve the mrsas(4) driver from LSI conflict. We have been looking at what needs to be done to get mrsas(4) into FreeBSD. I posted a change to FreeBSD SCSI list to add a tunable to reduce the probe priority of mfi(4) for ThunderBolt and later cards. This way they can both be in the GENERIC kernel etc. and not have an issue. We'll need to do some minor updates to your patch to work with that since I added another flag in the ident area. Sorry for the delay getting back to you. Thanks, Doug A. From owner-freebsd-scsi@FreeBSD.ORG Fri Jan 24 18:55:05 2014 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D4892AE5; Fri, 24 Jan 2014 18:55:05 +0000 (UTC) Received: from mail.ambrisko.com (mail.ambrisko.com [70.91.206.90]) by mx1.freebsd.org (Postfix) with ESMTP id A5F061EB1; Fri, 24 Jan 2014 18:55:05 +0000 (UTC) X-Ambrisko-Me: Yes Received: from server2.ambrisko.com (HELO internal.ambrisko.com) ([192.168.1.2]) by ironport.ambrisko.com with ESMTP; 24 Jan 2014 10:58:25 -0800 Received: from ambrisko.com (localhost [127.0.0.1]) by internal.ambrisko.com (8.14.4/8.14.4) with ESMTP id s0OIru3u033181; Fri, 24 Jan 2014 10:53:56 -0800 (PST) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.14.4/8.14.4/Submit) id s0OIrum4033180; Fri, 24 Jan 2014 10:53:56 -0800 (PST) (envelope-from ambrisko) Date: Fri, 24 Jan 2014 10:53:56 -0800 From: Doug Ambrisko To: Doug Ambrisko Subject: Re: LSI - MR-Fusion controller driver patch and man page Message-ID: <20140124185356.GA28724@ambrisko.com> References: <08ba2a262fba45f687cdd3225f325110@BN1PR07MB247.namprd07.prod.outlook.com> <20140103211449.GA69721@cisco.com> <8c423414ecc2421fbace3eb9f386be91@BN1PR07MB247.namprd07.prod.outlook.com> <20140106182935.GC93278@cisco.com> <20140107181139.GC2080@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140107181139.GC2080@cisco.com> User-Agent: Mutt/1.4.2.3i X-Mailman-Approved-At: Fri, 24 Jan 2014 19:43:48 +0000 Cc: "scottl@netflix.com" , "Radford, Adam" , "Kenneth D. Merry" , "sean_bruno@yahoo.com" , "Mankani, Krishnaraddi" , "dwhite@ixsystems.com" , "Maloy, Joe" , "jpaetzel@freebsd.org" , "freebsd-scsi@freebsd.org" , "McConnell, Stephen" X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 18:55:05 -0000 On Tue, Jan 07, 2014 at 10:11:39AM -0800, Doug Ambrisko wrote: [snip] | Yes, we can probably make the minimal change to mfi to allow mrsas to | optionally take over. That can probably be done the quickest. Here is the patch I propose to mfi(4) to allow mrsas(4) to optionally take newer cards. Index: mfi_pci.c =================================================================== --- mfi_pci.c (revision 260231) +++ mfi_pci.c (working copy) @@ -112,6 +112,11 @@ SYSCTL_INT(_hw_mfi, OID_AUTO, msi, CTLFLAG_RDTUN, &mfi_msi, 0, "Enable use of MSI interrupts"); +static int mfi_mrsas_enable = 0; +TUNABLE_INT("hw.mfi.mrsas_enable", &mfi_msi); +SYSCTL_INT(_hw_mfi, OID_AUTO, mrsas_enable, CTLFLAG_RDTUN, &mfi_mrsas_enable, + 0, "Allow mrasas to take newer cards"); + struct mfi_ident { uint16_t vendor; uint16_t device; @@ -127,11 +132,11 @@ {0x1000, 0x005b, 0x1028, 0x1f34, MFI_FLAGS_SKINNY| MFI_FLAGS_TBOLT, "Dell PERC H710P Mini (monolithics)"}, {0x1000, 0x005b, 0x1028, 0x1f35, MFI_FLAGS_SKINNY| MFI_FLAGS_TBOLT, "Dell PERC H710 Adapter"}, {0x1000, 0x005b, 0x1028, 0x1f37, MFI_FLAGS_SKINNY| MFI_FLAGS_TBOLT, "Dell PERC H710 Mini (blades)"}, - {0x1000, 0x005b, 0x1028, 0x1f38, MFI_FLAGS_SKINNY| MFI_FLAGS_TBOLT, "Dell PERC H710 Mini (monolithics)"}, - {0x1000, 0x005b, 0x8086, 0x9265, MFI_FLAGS_SKINNY| MFI_FLAGS_TBOLT, "Intel (R) RAID Controller RS25DB080"}, - {0x1000, 0x005b, 0x8086, 0x9285, MFI_FLAGS_SKINNY| MFI_FLAGS_TBOLT, "Intel (R) RAID Controller RS25NB008"}, - {0x1000, 0x005b, 0xffff, 0xffff, MFI_FLAGS_SKINNY| MFI_FLAGS_TBOLT, "ThunderBolt"}, - {0x1000, 0x005d, 0xffff, 0xffff, MFI_FLAGS_SKINNY| MFI_FLAGS_TBOLT, "Invader"}, + {0x1000, 0x005b, 0x1028, 0x1f38, MFI_FLAGS_SKINNY| MFI_FLAGS_TBOLT| MFI_FLAGS_MRSAS, "Dell PERC H710 Mini (monolithics)"}, + {0x1000, 0x005b, 0x8086, 0x9265, MFI_FLAGS_SKINNY| MFI_FLAGS_TBOLT| MFI_FLAGS_MRSAS, "Intel (R) RAID Controller RS25DB080"}, + {0x1000, 0x005b, 0x8086, 0x9285, MFI_FLAGS_SKINNY| MFI_FLAGS_TBOLT| MFI_FLAGS_MRSAS, "Intel (R) RAID Controller RS25NB008"}, + {0x1000, 0x005b, 0xffff, 0xffff, MFI_FLAGS_SKINNY| MFI_FLAGS_TBOLT| MFI_FLAGS_MRSAS, "ThunderBolt"}, + {0x1000, 0x005d, 0xffff, 0xffff, MFI_FLAGS_SKINNY| MFI_FLAGS_TBOLT| MFI_FLAGS_MRSAS, "Invader"}, {0x1000, 0x0060, 0x1028, 0xffff, MFI_FLAGS_1078, "Dell PERC 6"}, {0x1000, 0x0060, 0xffff, 0xffff, MFI_FLAGS_1078, "LSI MegaSAS 1078"}, {0x1000, 0x0071, 0xffff, 0xffff, MFI_FLAGS_SKINNY, "Drake Skinny"}, @@ -178,7 +183,13 @@ if ((id = mfi_find_ident(dev)) != NULL) { device_set_desc(dev, id->desc); - return (BUS_PROBE_DEFAULT); + + /* give priority to mrsas if tunable set */ + TUNABLE_INT_FETCH("hw.mfi.mrsas_enable", &mfi_mrsas_enable); + if ((id->flags & MFI_FLAGS_MRSAS) && mfi_mrsas_enable) + return (BUS_PROBE_LOW_PRIORITY); + else + return (BUS_PROBE_DEFAULT); } return (ENXIO); } Index: mfivar.h =================================================================== --- mfivar.h (revision 260231) +++ mfivar.h (working copy) @@ -199,6 +199,7 @@ #define MFI_FLAGS_GEN2 (1<<6) #define MFI_FLAGS_SKINNY (1<<7) #define MFI_FLAGS_TBOLT (1<<8) +#define MFI_FLAGS_MRSAS (1<<9) // Start: LSIP200113393 bus_dma_tag_t verbuf_h_dmat; bus_dmamap_t verbuf_h_dmamap; This creates a hw.mfi.mrsas_enable tunable to control it. The method via hints wasn't the best since for one the unit index was being abused a non-unit specfic option. It was also a little strange to have mrsas hint be in mfi(4). Then we need a minor change to mrsas.c --- ../mrsas.orig/mrsas.c 2014-01-03 11:30:28.000000000 -0800 +++ ./mrsas.c 2014-01-24 10:43:20.000000000 -0800 @@ -328,25 +328,11 @@ static struct mrsas_ident * mrsas_find_i static int mrsas_probe(device_t dev) { struct mrsas_ident *id; - unsigned int force = 0, ivar; if ((id = mrsas_find_ident(dev)) != NULL) { - if (id->device == 0x005b || id->device == 0x005d) { - resource_int_value("mrsas", 0, "fusion_force", &ivar); - - if (ivar == 0 || ivar == 1) - force = ivar; - - device_set_desc(dev, id->desc); - if (force) - return (BUS_PROBE_DEFAULT); - //return (BUS_PROBE_SPECIFIC); //give priority to MFI driver - else - return (BUS_PROBE_LOW_PRIORITY); - } - else - device_set_desc(dev, id->desc); - return (BUS_PROBE_DEFAULT); + device_set_desc(dev, id->desc); + /* between BUS_PROBE_DEFAULT and BUS_PROBE_LOW_PRIORITY */ + return (-30); } return (ENXIO); So that its probe part way between mfi(4) results and then it doesn't have to change. If no one has concerns then I'll check in the mfi(4) change. Thanks, Doug A. From owner-freebsd-scsi@FreeBSD.ORG Fri Jan 24 19:00:48 2014 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BFCB6BCC; Fri, 24 Jan 2014 19:00:48 +0000 (UTC) Received: from mail.ambrisko.com (mail.ambrisko.com [70.91.206.90]) by mx1.freebsd.org (Postfix) with ESMTP id 914831F44; Fri, 24 Jan 2014 19:00:48 +0000 (UTC) X-Ambrisko-Me: Yes Received: from server2.ambrisko.com (HELO internal.ambrisko.com) ([192.168.1.2]) by ironport.ambrisko.com with ESMTP; 24 Jan 2014 11:05:16 -0800 Received: from ambrisko.com (localhost [127.0.0.1]) by internal.ambrisko.com (8.14.4/8.14.4) with ESMTP id s0OJ0l7q035760; Fri, 24 Jan 2014 11:00:47 -0800 (PST) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.14.4/8.14.4/Submit) id s0OJ0lLr035759; Fri, 24 Jan 2014 11:00:47 -0800 (PST) (envelope-from ambrisko) Date: Fri, 24 Jan 2014 11:00:47 -0800 From: Doug Ambrisko To: Doug Ambrisko Subject: Re: LSI - MR-Fusion controller driver patch and man page Message-ID: <20140124190047.GA34975@ambrisko.com> References: <08ba2a262fba45f687cdd3225f325110@BN1PR07MB247.namprd07.prod.outlook.com> <20140103211449.GA69721@cisco.com> <8c423414ecc2421fbace3eb9f386be91@BN1PR07MB247.namprd07.prod.outlook.com> <20140106182935.GC93278@cisco.com> <20140107181139.GC2080@cisco.com> <20140124185356.GA28724@ambrisko.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140124185356.GA28724@ambrisko.com> User-Agent: Mutt/1.4.2.3i X-Mailman-Approved-At: Fri, 24 Jan 2014 19:43:58 +0000 Cc: "scottl@netflix.com" , "Radford, Adam" , "Kenneth D. Merry" , "sean_bruno@yahoo.com" , "Mankani, Krishnaraddi" , "dwhite@ixsystems.com" , "Maloy, Joe" , "jpaetzel@freebsd.org" , "freebsd-scsi@freebsd.org" , "McConnell, Stephen" X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 19:00:48 -0000 On Fri, Jan 24, 2014 at 10:53:56AM -0800, Doug Ambrisko wrote: | On Tue, Jan 07, 2014 at 10:11:39AM -0800, Doug Ambrisko wrote: | [snip] | | Yes, we can probably make the minimal change to mfi to allow mrsas to | | optionally take over. That can probably be done the quickest. | | Here is the patch I propose to mfi(4) to allow mrsas(4) to optionally take | newer cards. I noticed that this patch is partially incomplete since I didn't have FLAGS_MRSAS added to all of the TBOLT ID's. I'll fix that in the commit. | Index: mfi_pci.c | =================================================================== | --- mfi_pci.c (revision 260231) | +++ mfi_pci.c (working copy) | @@ -112,6 +112,11 @@ | SYSCTL_INT(_hw_mfi, OID_AUTO, msi, CTLFLAG_RDTUN, &mfi_msi, 0, | "Enable use of MSI interrupts"); | | +static int mfi_mrsas_enable = 0; | +TUNABLE_INT("hw.mfi.mrsas_enable", &mfi_msi); | +SYSCTL_INT(_hw_mfi, OID_AUTO, mrsas_enable, CTLFLAG_RDTUN, &mfi_mrsas_enable, | + 0, "Allow mrasas to take newer cards"); | + | struct mfi_ident { | uint16_t vendor; | uint16_t device; | @@ -127,11 +132,11 @@ | {0x1000, 0x005b, 0x1028, 0x1f34, MFI_FLAGS_SKINNY| MFI_FLAGS_TBOLT, "Dell PERC H710P Mini (monolithics)"}, | {0x1000, 0x005b, 0x1028, 0x1f35, MFI_FLAGS_SKINNY| MFI_FLAGS_TBOLT, "Dell PERC H710 Adapter"}, | {0x1000, 0x005b, 0x1028, 0x1f37, MFI_FLAGS_SKINNY| MFI_FLAGS_TBOLT, "Dell PERC H710 Mini (blades)"}, | - {0x1000, 0x005b, 0x1028, 0x1f38, MFI_FLAGS_SKINNY| MFI_FLAGS_TBOLT, "Dell PERC H710 Mini (monolithics)"}, | - {0x1000, 0x005b, 0x8086, 0x9265, MFI_FLAGS_SKINNY| MFI_FLAGS_TBOLT, "Intel (R) RAID Controller RS25DB080"}, | - {0x1000, 0x005b, 0x8086, 0x9285, MFI_FLAGS_SKINNY| MFI_FLAGS_TBOLT, "Intel (R) RAID Controller RS25NB008"}, | - {0x1000, 0x005b, 0xffff, 0xffff, MFI_FLAGS_SKINNY| MFI_FLAGS_TBOLT, "ThunderBolt"}, | - {0x1000, 0x005d, 0xffff, 0xffff, MFI_FLAGS_SKINNY| MFI_FLAGS_TBOLT, "Invader"}, | + {0x1000, 0x005b, 0x1028, 0x1f38, MFI_FLAGS_SKINNY| MFI_FLAGS_TBOLT| MFI_FLAGS_MRSAS, "Dell PERC H710 Mini (monolithics)"}, | + {0x1000, 0x005b, 0x8086, 0x9265, MFI_FLAGS_SKINNY| MFI_FLAGS_TBOLT| MFI_FLAGS_MRSAS, "Intel (R) RAID Controller RS25DB080"}, | + {0x1000, 0x005b, 0x8086, 0x9285, MFI_FLAGS_SKINNY| MFI_FLAGS_TBOLT| MFI_FLAGS_MRSAS, "Intel (R) RAID Controller RS25NB008"}, | + {0x1000, 0x005b, 0xffff, 0xffff, MFI_FLAGS_SKINNY| MFI_FLAGS_TBOLT| MFI_FLAGS_MRSAS, "ThunderBolt"}, | + {0x1000, 0x005d, 0xffff, 0xffff, MFI_FLAGS_SKINNY| MFI_FLAGS_TBOLT| MFI_FLAGS_MRSAS, "Invader"}, | {0x1000, 0x0060, 0x1028, 0xffff, MFI_FLAGS_1078, "Dell PERC 6"}, | {0x1000, 0x0060, 0xffff, 0xffff, MFI_FLAGS_1078, "LSI MegaSAS 1078"}, | {0x1000, 0x0071, 0xffff, 0xffff, MFI_FLAGS_SKINNY, "Drake Skinny"}, | @@ -178,7 +183,13 @@ | | if ((id = mfi_find_ident(dev)) != NULL) { | device_set_desc(dev, id->desc); | - return (BUS_PROBE_DEFAULT); | + | + /* give priority to mrsas if tunable set */ | + TUNABLE_INT_FETCH("hw.mfi.mrsas_enable", &mfi_mrsas_enable); | + if ((id->flags & MFI_FLAGS_MRSAS) && mfi_mrsas_enable) | + return (BUS_PROBE_LOW_PRIORITY); | + else | + return (BUS_PROBE_DEFAULT); | } | return (ENXIO); | } | Index: mfivar.h | =================================================================== | --- mfivar.h (revision 260231) | +++ mfivar.h (working copy) | @@ -199,6 +199,7 @@ | #define MFI_FLAGS_GEN2 (1<<6) | #define MFI_FLAGS_SKINNY (1<<7) | #define MFI_FLAGS_TBOLT (1<<8) | +#define MFI_FLAGS_MRSAS (1<<9) | // Start: LSIP200113393 | bus_dma_tag_t verbuf_h_dmat; | bus_dmamap_t verbuf_h_dmamap; | | This creates a hw.mfi.mrsas_enable tunable to control it. The | method via hints wasn't the best since for one the unit index was | being abused a non-unit specfic option. It was also a little strange | to have mrsas hint be in mfi(4). | | Then we need a minor change to mrsas.c | | | --- ../mrsas.orig/mrsas.c 2014-01-03 11:30:28.000000000 -0800 | +++ ./mrsas.c 2014-01-24 10:43:20.000000000 -0800 | @@ -328,25 +328,11 @@ static struct mrsas_ident * mrsas_find_i | static int mrsas_probe(device_t dev) | { | struct mrsas_ident *id; | - unsigned int force = 0, ivar; | | if ((id = mrsas_find_ident(dev)) != NULL) { | - if (id->device == 0x005b || id->device == 0x005d) { | - resource_int_value("mrsas", 0, "fusion_force", &ivar); | - | - if (ivar == 0 || ivar == 1) | - force = ivar; | - | - device_set_desc(dev, id->desc); | - if (force) | - return (BUS_PROBE_DEFAULT); | - //return (BUS_PROBE_SPECIFIC); //give priority to MFI driver | - else | - return (BUS_PROBE_LOW_PRIORITY); | - } | - else | - device_set_desc(dev, id->desc); | - return (BUS_PROBE_DEFAULT); | + device_set_desc(dev, id->desc); | + /* between BUS_PROBE_DEFAULT and BUS_PROBE_LOW_PRIORITY */ | + return (-30); | } | return (ENXIO); | | So that its probe part way between mfi(4) results and then it doesn't have | to change. | | If no one has concerns then I'll check in the mfi(4) change. Thanks, Doug A. From owner-freebsd-scsi@FreeBSD.ORG Sat Jan 25 05:44:49 2014 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 51DA1C01 for ; Sat, 25 Jan 2014 05:44:49 +0000 (UTC) Received: from mail-qa0-x235.google.com (mail-qa0-x235.google.com [IPv6:2607:f8b0:400d:c00::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0CAC2118C for ; Sat, 25 Jan 2014 05:44:48 +0000 (UTC) Received: by mail-qa0-f53.google.com with SMTP id cm18so4876751qab.40 for ; Fri, 24 Jan 2014 21:44:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=Z6h9NfHmL3Ft12eiNuk6ZaHIeLfJZmQTdW5rQbBxd3Q=; b=nFCLIJerUw4jQNtPMuFBtAtreiQjTihVrwgZ/JbeGfa9PKrNfzYvzXuu0tabroC/Vr SDiojkLTfJm1KGgwR6kt5cFKX2+vAwulr7LAWhy5ewqjJGNjhVjmzTcV+jv2M2lIf4ZI 2aDA4ecaD5zD1Dq79n40Hyv7TnwJ6xyGPcFWBUjKVMrXFyzVoW+3k9T6jAjnTW6ASeZ3 3EWjFDmFT9ZtMO3jFzS0a/TA9gY0AGTN7kQo3Fj5IQ8L/Z0gqRp5JabJUdWb4XY+tGtT JW6jYfw1s8fDnzclh8To0MtgEeB+vkCyeqCh+vda6il+CdPbqwUaxo2m73LTBUAKNibo VNLA== MIME-Version: 1.0 X-Received: by 10.224.3.10 with SMTP id 10mr26333197qal.58.1390628688231; Fri, 24 Jan 2014 21:44:48 -0800 (PST) Sender: benlaurie@gmail.com Received: by 10.96.142.194 with HTTP; Fri, 24 Jan 2014 21:44:48 -0800 (PST) In-Reply-To: References: <84D23688-DDC6-421E-9D21-3DA646229038@scsiguy.com> Date: Sat, 25 Jan 2014 05:44:48 +0000 X-Google-Sender-Auth: V_8GZUvRjkilzpDrK9mBr0OH6Gg Message-ID: Subject: Re: Dropped interrupts From: Ben Laurie To: "Justin T. Gibbs" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: freebsd-scsi@freebsd.org X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jan 2014 05:44:49 -0000 Aha, finally got the error again... ahc0: Recovery Initiated >>>>>>>>>>>>>>>>>> Dump Card State Begins <<<<<<<<<<<<<<<<< ahc0: Dumping Card State in Command phase, at SEQADDR 0x16c Card was paused ACCUM =3D 0x80, SINDEX =3D 0xa0, DINDEX =3D 0xe4, ARG_2 =3D 0x3e HCNT =3D 0x0 SCBPTR =3D 0x0 SCSIPHASE[0x0] SCSISIGI[0x84]:(BSYI|CDI) ERROR[0x0] SCSIBUSL[0x80] LASTPHASE[0x80]:(CDI) SCSISEQ[0x12]:(ENAUTOATNP|ENRSELI) SBLKCTL[0xa]:(SELWIDE|SELBUSB) SCSIRATE[0xc2]:(ENABLE_CRC|WIDEXFER) SEQCTL[0x10]:(FASTMODE) SEQ_FLAGS[0x0] SSTAT0[0x7]:(DMADONE|SPIORDY|SDONE) SSTAT1[0x0] SSTAT2[0x0] SSTAT3[0x0] SIMODE0[0x8]:(ENSWRAP) SIMODE1[0xac]:(ENSCSIPERR|ENBUSFREE|ENSCSIRST|ENSELTIMO) SXFRCTL0[0x88]:(SPIOEN|DFON) DFCNTRL[0x4]:(DIRECTION) DFSTATUS[0x89]:(FIFOEMP|HDONE|PRELOAD_AVAIL) STACK: 0x34 0x0 0x164 0x179 SCB count =3D 254 Kernel NEXTQSCB =3D 238 Card NEXTQSCB =3D 238 QINFIFO entries: Waiting Queue entries: Disconnected Queue entries: QOUTFIFO entries: Sequencer Free SCB List: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 Sequencer SCB Info: 0 SCB_CONTROL[0x0] SCB_SCSIID[0x27] SCB_LUN[0x0] SCB_TAG[0xfb] 1 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] 2 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] 3 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] 4 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] 5 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] 6 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] 7 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] 8 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] 9 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] 10 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] 11 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] 12 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] 13 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] 14 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] 15 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] 16 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] 17 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] 18 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] 19 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] 20 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] 21 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] 22 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] 23 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] 24 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] 25 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] 26 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] 27 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] 28 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] 29 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] 30 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] 31 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] Pending list: 251 SCB_CONTROL[0x0] SCB_SCSIID[0x27] SCB_LUN[0x0] Kernel Free SCB list: 239 240 241 242 243 244 245 246 247 248 249 250 252 253 237 236 235 234 233 232 231 230 229 228 227 226 225 224 223 222 221 220 219 218 217 216 215 214 213 212 211 210 209 208 207 206 205 204 203 202 201 200 199 198 197 196 195 194 193 192 191 190 189 188 187 186 185 184 183 182 181 180 179 178 177 176 175 174 173 172 171 170 169 168 167 166 165 164 163 162 161 160 159 158 157 156 155 154 153 152 151 150 149 148 147 146 145 144 143 142 141 140 139 138 137 136 135 134 133 132 131 130 129 128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 109 108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 Untagged Q(2): 251 <<<<<<<<<<<<<<<<< Dump Card State Ends >>>>>>>>>>>>>>>>>> (sa0:ahc0:0:2:0): Timed out scb:0xc43b2dc0 control:0x0 scsiid:0x27 lun:0 cdb_len:6 Shared Data: 0xa00000xfc00000x3c0x200000000 dataptr:0x1b5f1028 datacnt:0xfd8 sgptr:0x23c700a tag:0xfb sg[0] - Addr 0x01b5f1028 : Length 4056 sg[1] - Addr 0x0d732000 : Length 8192 sg[2] - Addr 0x01a9f4000 : Length 8192 sg[3] - Addr 0x01ae26000 : Length 8192 sg[4] - Addr 0x01263a000 : Length 8192 sg[5] - Addr 0x01c258000 : Length 8192 sg[6] - Addr 0x0a63a000 : Length 8192 sg[7] - Addr 0x017276000 : Length 8192 sg[8] - Addr 0x08551000 : Length -2147480536 (sa0:ahc0:0:2:0): BDR message in message buffer ahc0: Recovery Initiated >>>>>>>>>>>>>>>>>> Dump Card State Begins <<<<<<<<<<<<<<<<< ahc0: Dumping Card State in Command phase, at SEQADDR 0x16c Card was paused ACCUM =3D 0x80, SINDEX =3D 0xa0, DINDEX =3D 0xe4, ARG_2 =3D 0x3e HCNT =3D 0x0 SCBPTR =3D 0x0 SCSIPHASE[0x0] SCSISIGI[0x94]:(BSYI|ATNI|CDI) ERROR[0x0] SCSIBUSL[0x80] LASTPHASE[0x80]:(CDI) SCSISEQ[0x12]:(ENAUTOATNP|ENRSELI) SBLKCTL[0xa]:(SELWIDE|SELBUSB) SCSIRATE[0xc2]:(ENABLE_CRC|WIDEXFER) SEQCTL[0x10]:(FASTMODE) SEQ_FLAGS[0x0] SSTAT0[0x7]:(DMADONE|SPIORDY|SDONE) SSTAT1[0x0] SSTAT2[0x0] SSTAT3[0x0] SIMODE0[0x8]:(ENSWRAP) SIMODE1[0xac]:(ENSCSIPERR|ENBUSFREE|ENSCSIRST|ENSELTIMO) SXFRCTL0[0x88]:(SPIOEN|DFON) DFCNTRL[0x4]:(DIRECTION) DFSTATUS[0x89]:(FIFOEMP|HDONE|PRELOAD_AVAIL) STACK: 0x34 0x0 0x164 0x179 SCB count =3D 254 Kernel NEXTQSCB =3D 238 Card NEXTQSCB =3D 238 QINFIFO entries: Waiting Queue entries: Disconnected Queue entries: QOUTFIFO entries: Sequencer Free SCB List: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 Sequencer SCB Info: 0 SCB_CONTROL[0x0] SCB_SCSIID[0x27] SCB_LUN[0x0] SCB_TAG[0xfb] 1 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] 2 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] 3 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] 4 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] 5 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] 6 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] 7 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] 8 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] 9 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] 10 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] 11 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] 12 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] 13 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] 14 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] 15 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] 16 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] 17 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] 18 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] 19 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] 20 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] 21 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] 22 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] 23 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] 24 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] 25 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] 26 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] 27 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] 28 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] 29 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] 30 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] 31 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] Pending list: 251 SCB_CONTROL[0x0] SCB_SCSIID[0x27] SCB_LUN[0x0] Kernel Free SCB list: 239 240 241 242 243 244 245 246 247 248 249 250 252 253 237 236 235 234 233 232 231 230 229 228 227 226 225 224 223 222 221 220 219 218 217 216 215 214 213 212 211 210 209 208 207 206 205 204 203 202 201 200 199 198 197 196 195 194 193 192 191 190 189 188 187 186 185 184 183 182 181 180 179 178 177 176 175 174 173 172 171 170 169 168 167 166 165 164 163 162 161 160 159 158 157 156 155 154 153 152 151 150 149 148 147 146 145 144 143 142 141 140 139 138 137 136 135 134 133 132 131 130 129 128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 109 108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 Untagged Q(2): 251 <<<<<<<<<<<<<<<<< Dump Card State Ends >>>>>>>>>>>>>>>>>> (sa0:ahc0:0:2:0): Timed out scb:0xc43b2dc0 control:0x0 scsiid:0x27 lun:0 cdb_len:6 Shared Data: 0xa00000xfc00000x3c0x200000000 dataptr:0x1b5f1028 datacnt:0xfd8 sgptr:0x23c700a tag:0xfb sg[0] - Addr 0x01b5f1028 : Length 4056 sg[1] - Addr 0x0d732000 : Length 8192 sg[2] - Addr 0x01a9f4000 : Length 8192 sg[3] - Addr 0x01ae26000 : Length 8192 sg[4] - Addr 0x01263a000 : Length 8192 sg[5] - Addr 0x01c258000 : Length 8192 sg[6] - Addr 0x0a63a000 : Length 8192 sg[7] - Addr 0x017276000 : Length 8192 sg[8] - Addr 0x08551000 : Length -2147480536 (sa0:ahc0:0:2:0): no longer in timeout, status =3D 24b ahc0: Issued Channel A Bus Reset. 1 SCBs aborted (sa0:ahc0:0:2:0): WRITE(6). CDB: 0a 00 00 fc 00 00 (sa0:ahc0:0:2:0): CAM status: Command timeout (sa0:ahc0:0:2:0): Error 5, Retries exhausted (sa0:ahc0:0:2:0): MODE SENSE(6). CDB: 1a 00 0f 00 1c 00 (sa0:ahc0:0:2:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, or bus device reset occurred) (sa0:ahc0:0:2:0): Field Replaceable Unit: 48 On 9 January 2014 07:37, Ben Laurie wrote: > On 8 January 2014 06:44, Ben Laurie wrote: >> On 7 January 2014 18:11, Justin T. Gibbs wrote: >>> On Jan 7, 2014, at 12:36 AM, Ben Laurie wrote: >>> >>>> Attached. >>>> >>>> On 7 January 2014 05:46, Justin T. Gibbs wrote: >>>>> On Jan 6, 2014, at 3:01 PM, Ben Laurie wrote: >>>>> >>>>>> Not subscribed to the list, so please cc on replies. >>>>>> >>>>>> I'm using Bacula with an LTO-2 SCSI drive. >>>>>> >>>>>> With increasing frequency lately, I've been getting errors like this >>>>>> from bacula: >>>>>> >>>>>> backup-sd JobId 13092: Error: block.c:608 Write error at 23:6772 on >>>>>> device "Ultrium" (/dev/nsa0). ERR=3DOperation not permitted. >>>>>> >>>>>> Associated with this, I see in dmesg: >>>>>> >>>>>> ahc0: Recovery Initiated >>>>>> >>>>>> [a lot of dump info, including=85] >>>>> >>>>> If you provide the dump info, I may be able to tell you why recovery = is starting. >>>>> >>>>> The dmesg information from a boot of the system would be good to have= too. >>>>> >>>>> =97 >>>>> Justin >>> >>> The target is keeping us in command phase for some reason. No parity o= r other >>> errors are being reported. My guess is that the tape drive does not li= ke the command >>> that was issued for some reason. >>> >>> Attached are two totally untested/uncompiled changes for you to try out= . The first >>> should give more information about the command that timed out so we can= better >>> determine if it is well formed. The second is an attempted fix for spu= rious >>> =93Interrupts may not be functioning=94 warnings. Can you attempt to r= eplicate this >>> again with these changes? >> >> Rebuilding now - you had a ; missing in the patch :-) >> >> Of course, now I've done this, it'll not fail for a month (its been >> failing multiple times per day recently, but on average its a lot >> rarer than that!). >> >> Will let you know when I get a fresh failure. > > As predicted, it has now done 3 complete tapes with no problems, and > is on the fourth. From owner-freebsd-scsi@FreeBSD.ORG Sat Jan 25 17:15:22 2014 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 89C3FA4E for ; Sat, 25 Jan 2014 17:15:22 +0000 (UTC) Received: from aslan.scsiguy.com (www.scsiguy.com [70.89.174.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5BE301179 for ; Sat, 25 Jan 2014 17:15:21 +0000 (UTC) Received: from [192.168.0.61] (jt-mbp.home.scsiguy.org [192.168.0.61]) (authenticated bits=0) by aslan.scsiguy.com (8.14.7/8.14.7) with ESMTP id s0PHFDhr066148 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 25 Jan 2014 10:15:15 -0700 (MST) (envelope-from gibbs@scsiguy.com) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: Dropped interrupts From: "Justin T. Gibbs" In-Reply-To: Date: Sat, 25 Jan 2014 10:15:12 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8680A21D-78D7-4B65-A502-17F0C3B70291@scsiguy.com> References: <84D23688-DDC6-421E-9D21-3DA646229038@scsiguy.com> To: Ben Laurie X-Mailer: Apple Mail (2.1827) Cc: freebsd-scsi@freebsd.org X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jan 2014 17:15:22 -0000 On Jan 24, 2014, at 10:44 PM, Ben Laurie wrote: > Aha, finally got the error again=85 I don=92t know enough about your backup or Bacula to know if this is = amount that should be written, but we attempted a write in variable = block mode of 64512 bytes. The command, data transfer list, and = controller state are all consistent with this. The command was = successfully transferred to the tape drive, but it never transitioned to = data phase to allow us to begin the data transfer. (In parallel SCSI, = the target controls all state transitions). Since there are no parity errors or other indications of a transport = error, my hunch is that this is a tape drive issue. Are you running the = latest available firmware for it? How many write cycles do you have on = your media? When was the last time you cleaned the drive? There are still some bugs in the formatting of the diagnostic output for = this driver. I=92ll fix these up and get them into HEAD. =97 Justin=