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

["H. Peter Anvin" <hpa@zytor.com>]

On 04/12/2010 02:56 PM, Matthew Wilcox wrote:
> On Mon, Apr 12, 2010 at 11:56:41AM -0600, Bjorn Helgaas wrote:
>> 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.
> 
> Perhaps it's sufficient to try them in reverse order?

Why bother?  The first megabyte is really special in x86... it is
historically used for legacy devices, it has specific functions for PCI
firmware, and it has separate MTRRs.

Simply put, "there there be dragons".  There is no sane reason to
allocate unassigned devices there (preassigned devices is another matter).

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.