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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Mon, 12 Apr 2010 19:14:22 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Matthew Wilcox <willy@...ux.intel.com>
CC:	Bjorn Helgaas <bjorn.helgaas@...com>,
	Andy Isaacson <adi@...apodia.org>,
	linux-kernel@...r.kernel.org,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	Chris Wright <chrisw@...s-sol.org>,
	Yinghai Lu <yinghai@...nel.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>
Subject: Re: [2.6.34-rc1 REGRESSION] ahci 0000:00:1f.2: controller reset	failed
 (0xffffffff)

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.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/