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

[Alexander Motin]

Nathan Lay wrote:
>> 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},
>>
> 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. 

It is actually more correct, but less effective approach. Theoretically
BIOS should configure controller to report SATA subclass and AHCI
progif. But as soon as not all BIOS'es able to do that, that array of
quirks used. But that quirk approach is not working fine (complicated
and vendor-specific) for Intel chipsets, so I have added NOFORCE quirk,
needed to fix your problem.

> 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.

You should first talk to you BIOS. If it is able to enable AHCI - you
are lucky. Else it is not solvable without dirty vendor-specific code,
messing resource management, as now your controller is not providing
resources needed for AHCI operation.

-- 
Alexander Motin