Date: Fri, 25 Dec 2009 09:38:08 +0200 From: Alexander Motin <mav@FreeBSD.org> To: Nathan Lay <nslay@comcast.net> Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: 8-STABLE ahci fails to attach, does not fallback on ataahci Message-ID: <4B346BE0.2010909@FreeBSD.org> In-Reply-To: <1261707782.00199010.1261696205@10.7.7.3> References: <1261707782.00199010.1261696205@10.7.7.3>
next in thread | previous in thread | raw e-mail | index | archive | help
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},
--
Alexander Motin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4B346BE0.2010909>