Date: Fri, 25 Dec 2009 22:02:28 -0500 From: Nathan Lay <nslay@comcast.net> To: Alexander Motin <mav@FreeBSD.org> Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: 8-STABLE ahci fails to attach, does not fallback on ataahci Message-ID: <4B357CC4.9020909@comcast.net> In-Reply-To: <4B346BE0.2010909@FreeBSD.org> References: <1261707782.00199010.1261696205@10.7.7.3> <4B346BE0.2010909@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Alexander Motin wrote:
> Nathan Lay wrote:
>
>> I gave ATA_CAM a try last night and believe I have a similar setup
>> (crippled hardware) in my laptop as Doug Barton's, although my
>> controller is ICH6M. Nonetheless, ahci detects my controller and tries
>> to attach and fails (returns 6). No ada nodes are created and the boot
>> process halts trying to find a root mount. Verbose booting reveals
>> nothing special. Anything else I can do to try to reveal the problem?
>>
>> I tried modular ATA with the following:
>>
>> device atacore
>> device atapci
>> device ataahci
>> device ataintel
>>
>> device ahci
>>
>> From reading the lists more thoroughly, I now have the impression that
>> either ahci or ataahci are necessary and not both.
>>
>
> They duplicate each other, but should not conflict.
>
>
>> If I remove 'device
>> ahci' then 8-STABLE boots normally. However, I would think that if ahci
>> failed to attach then the kernel should fallback on ataahci. If GENERIC
>> included both ahci and ataahci, then I would never be able to boot
>> FreeBSD let alone install it.
>>
>
> There is no fallback mechanism on attach failure in newbus. ataahci will
> only be used is ahci fail probe, not an attach.
>
>
>> `uname -a`
>> FreeBSD LIGHTBULB.LOCAL 8.0-STABLE FreeBSD 8.0-STABLE #4: Thu Dec 24
>> 02:40:23 EST 2009
>> nslay@LIGHTBULB.LOCAL:/usr/obj/usr/src/sys/LIGHTBULB i386
>>
>> Here's what appears in my dmesg:
>> atapci0: <Intel ICH6M SATA150 controller> port
>> 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x18c0-0x18cf at device 31.2 on pci0
>>
>> and the result of `pciconf -lv`
>> atapci0@pci0:0:31:2: class=0x010180 card=0x056a1014 chip=0x26538086
>> rev=0x03 hdr=0x00
>> vendor = 'Intel Corporation'
>> device = '82801FBM (ICH6M) SATA Controller'
>> class = mass storage
>> subclass = ATA
>>
>
> There is the answer. ICH6 chipsets are using chip ID convention
> different from other ICHs. Same ID used for AHCI and legacy modes. It
> was false positive probe. This chip now runs in legacy mode.
>
> This patch should fix the issue:
>
> --- ahci.c.prev 2009-12-08 13:27:31.000000000 +0200
> +++ ahci.c 2009-12-25 09:28:32.000000000 +0200
> @@ -115,8 +115,8 @@ static struct {
> {0x43931002, "ATI IXP700", 0},
> {0x43941002, "ATI IXP800", 0},
> {0x43951002, "ATI IXP800", 0},
> - {0x26528086, "Intel ICH6", 0},
> - {0x26538086, "Intel ICH6M", 0},
> + {0x26528086, "Intel ICH6", AHCI_Q_NOFORCE},
> + {0x26538086, "Intel ICH6M", AHCI_Q_NOFORCE},
> {0x26818086, "Intel ESB2", 0},
> {0x26828086, "Intel ESB2", 0},
> {0x26838086, "Intel ESB2", 0},
>
>
Hi Alexander,
I also noticed in dmesg that ataahci never actually attaches (There's no
AHCI messages). I examined ahci.c and ata-ahci.c and noticed that
ata-ahci.c lacks the quirk table and code in ata_ahci_probe that would
normally match this chip in ahci_probe. I think that it's subclass
isn't PCIS_STORAGE_SATA. I tried to hardcode it to see if it would work
but I never successfully persuaded ataahci to attach. I'm not familiar
with kernel debugging or development and grew weary of constantly
recompiling the kernel to try things.
Best Regards,
Nathan Lay
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4B357CC4.9020909>