Date: Mon, 17 Nov 2014 16:39:41 +0000 From: Steven Hartland <killing@multiplay.co.uk> To: freebsd-stable@freebsd.org Subject: Re: aacraid drives missing after update 10.0 -> 10.1 ? Message-ID: <546A24CD.6040600@multiplay.co.uk> In-Reply-To: <D9A7B574-3C8D-4F6C-A87F-321B92C9A12A@sarenet.es> References: <20141116213910.GF44537@home.opsec.eu> <CAHEMsqbKHFatgWuVRbibxpFdmPLnnB76WWMfhcjoQjtk8g8udw@mail.gmail.com> <20141117143323.GH44537@home.opsec.eu> <5133298B-F884-4203-92A0-7D0FCFF72FE1@sarenet.es> <20141117145204.GI44537@home.opsec.eu> <D9A7B574-3C8D-4F6C-A87F-321B92C9A12A@sarenet.es>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?546A24CD.6040600>