Nathan Lay
2009-Dec-24  23:01 UTC
8-STABLE ahci fails to attach, does not fallback on ataahci
Hi lists,
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.  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.
`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
the kernel was built from 8-STABLE tree as of last night.
Best Regards,
Nathan Lay
Alexander Motin
2009-Dec-25  07:38 UTC
8-STABLE ahci fails to attach, does not fallback on ataahci
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 = ATAThere 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