Re: [2.6.34-rc1 REGRESSION] ahci 0000:00:1f.2: controller reset failed (0xffffffff)

[Bjorn Helgaas <bjorn.helgaas@hp.com>]

On Tuesday 06 April 2010 09:59:43 pm Bjorn Helgaas wrote:
> Would you mind trying the patch below and the patch and kernel args
> here:
>   https://bugzilla.kernel.org/show_bug.cgi?id=15533#c5
> 
> This will (1) reserve the VGA area, so we should put the AHCI device
> elsewhere, and (2) collect a few more details about exactly what the
> BIOS is reporting.

We established that the patch in the message above wasn't enough
(the patch reserved 0xa0000-0xbffff, and Linux moved the AHCI
controller to 0xc0000 instead of 0xa0000).

But I'd still like to see the details of what ACPI is telling us,
so if you wouldn't mind trying that patch from bugzilla:
  https://bugzilla.kernel.org/show_bug.cgi?id=15533#c5
and collecting an acpidump, and attaching both to the bug report:
  https://bugzilla.kernel.org/show_bug.cgi?id=15744
that would be great.

Linux thinks the windows are:
  pci_root PNP0A03:00: host bridge window [mem 0x000a0000-0x000bffff]
  pci_root PNP0A03:00: host bridge window [mem 0x000c0000-0x000effff]
  pci_root PNP0A03:00: host bridge window [mem 0x000f0000-0x000fffff]

The 0xa0000-0xbffff one makes good sense.  That's normally MMIO that's
routed via PCI to the VGA device frame buffer, and we should be able
to figure out how to avoid that area, e.g., by using BIOS info, PCI
class codes, etc.

Now we need to figure how to avoid the 0xc0000-0xeffff and 0xf0000-0xfffff
windows.  Maybe there's something special about how ACPI describes them.

Or maybe we're just unlucky because these are the first windows in the
_CRS list, and Linux tries them in order, while Windows uses a different
strategy.

Bjorn