From owner-freebsd-stable@FreeBSD.ORG Mon Nov 17 16:39:40 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3AB5B5A7 for ; Mon, 17 Nov 2014 16:39:40 +0000 (UTC) Received: from mail-wg0-f53.google.com (mail-wg0-f53.google.com [74.125.82.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D8AC112D for ; Mon, 17 Nov 2014 16:39:39 +0000 (UTC) Received: by mail-wg0-f53.google.com with SMTP id l18so1704098wgh.40 for ; Mon, 17 Nov 2014 08:39:38 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=IAJ20KchiwQr2OAeRCKivR5clqTVm4O92dURkbnpEy4=; b=RgpHpsU3DdJGWIi5gbrnT5Mdw20TZo0Xzbq4NiRCqS4K8goKJDwFdxznlJpdjMSEvR 0rtsvVd5E9KGQ+04hKWaGpB2YvhFhO/CfQQtnHhIzG9jWFzAmVRwmgyBb3QHX8KPJnRI jVSr2asN2ld2sVDwiv2r8rhQSHcnVjnjNs73A5kD4NNhbAYFTHMSXQCZWxKmUBtq+reH AtUU5T9uXalgwxUlw+/u3G3La7TsOmbJZayyvE7zrT3eYRUlrjaDg8sxgaQ7dVW01Lbk 1QXDcnZFXmRp6MOVd4sHIPBXTH3wesjJY3WVrle4FEpUpFxrgfQlbm1YOe5rdv5SBSXW w/Lw== X-Gm-Message-State: ALoCoQm5rIyy6p7dzGZ6X7d+vhe1EMS1qwWoNZNTqjCAdHx00yuODpQedSLbY3v00MDafW7sffkD X-Received: by 10.194.5.227 with SMTP id v3mr41155954wjv.63.1416242378134; Mon, 17 Nov 2014 08:39:38 -0800 (PST) Received: from [10.10.1.68] (82-69-141-170.dsl.in-addr.zen.co.uk. [82.69.141.170]) by mx.google.com with ESMTPSA id dc8sm15947513wib.7.2014.11.17.08.39.36 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Nov 2014 08:39:37 -0800 (PST) Message-ID: <546A24CD.6040600@multiplay.co.uk> Date: Mon, 17 Nov 2014 16:39:41 +0000 From: Steven Hartland User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: aacraid drives missing after update 10.0 -> 10.1 ? References: <20141116213910.GF44537@home.opsec.eu> <20141117143323.GH44537@home.opsec.eu> <5133298B-F884-4203-92A0-7D0FCFF72FE1@sarenet.es> <20141117145204.GI44537@home.opsec.eu> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 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 Nov 2014 16:39:40 -0000 On 17/11/2014 15:25, Borja Marcos wrote: > On Nov 17, 2014, at 3:52 PM, Kurt Jaeger wrote: > >> Hi! >> >>>>> If your running a custom kernel do you have both the options for aac enable: >>>> It's the GENERIC kernel. >>> That's curious. In order to have direct access to the disks I >>> had to patch aac_cam.c. Maybe you were >>> using a patched file and you forgot? >> I upgraded using freebsd-update and upgraded GENERIC. What additional >> patch would be needed ? > Beware, it's just my case, not necessarily others'. > > My controller (built-in in a SunFire X4240) I needed to comment out several lines > so that the passthrough driver attaches the disks to the "da" driver. It was suggested > back in 2007 (with flashing warnings all over the place!) by Scott Long answering > my question about ZFS and avoiding "intelligent RAID controller" features entirely. > > These are the two relevant threads: > http://lists.freebsd.org/pipermail/freebsd-scsi/2007-October/003223.html > http://lists.freebsd.org/pipermail/freebsd-scsi/2007-November/003234.html > > They are related to the "mfi" cards, but I posted them so that you have some historical context. > Of course now we know that it's far better to repurpose them by flashing with IT-mode firmware > (turning them into "HBA, period" devices). > > Back to our "aac". I have that SunFire machine in which I was unable to access > the disks individually. So I checked the source code for aac_cam.c and I found > out that the same trick works. > > This is what I do. Beware! This is working for me since 2012, but of course there's no guarantee. > At some point (with some 9. x version) the kludge stopped identifyng SSD disks connected to the > backplane, but it works with the SAS disks I am using. > > Again, USE WITH CAUTION! Something like this should be made more or less "official". > > > > --- aac_cam.c 2014-11-17 15:20:24.011457711 +0000 > +++ aac_cam.c.orig 2014-11-17 15:08:13.116702602 +0000 > @@ -129,7 +129,7 @@ > return; > } > > - if (xpt_create_path(&ccb->ccb_h.path, xpt_periph, > + if (xpt_create_path(&ccb->ccb_h.path, NULL, > cam_sim_path(camsc->sim), > target_id, CAM_LUN_WILDCARD) != CAM_REQ_CMP) { > xpt_free_ccb(ccb); > @@ -548,9 +548,8 @@ > /* > * We want DASD and PROC devices to only be > * visible through the pass device. > - * CHANGE: WE WANT DASD DEVICES VISIBLE! > */ > - if ((/* IGNORE THIS: (device == T_DIRECT) || */ > + if (((device == T_DIRECT) || > (device == T_PROCESSOR) || > (sc->flags & AAC_FLAGS_CAM_PASSONLY))) { > /* As you say that looks very hack. I'm wondering if the following commit was the cause: https://svnweb.freebsd.org/base?view=revision&revision=257847 Specifically: https://svnweb.freebsd.org/base/head/sys/dev/aacraid/aacraid_cam.c?annotate=257847&pathrev=257847#l1231 Could you try backing that out and see if it fixes it for you? Regards Steve