aacraid drives missing after update 10.0 -> 10.1 ?
Steven Hartland
killing at multiplay.co.uk
Mon Nov 17 16:39:40 UTC 2014
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
More information about the freebsd-stable
mailing list