Re: 8-STABLE ahci fails to attach, does not fallback on ataahci

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_at_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_at_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
> _at__at_ -115,8 +115,8 _at__at_ 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