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