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>
index | next in thread | previous in thread | raw e-mail
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
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4B357CC4.9020909>