Created attachment 85671 [details] dmesg log For all BIOSes tested (original A04 -08/21/2008 & most recent A11 - 04/30/2012), the ACPI CRS table entry for one of the PCI host bridge windows is incorrect. Specifically, pci_bus 0000:00: root bus resource [mem 0xf0000000-0xfe000000] This host bridge window should end @ 0xfdffffff. Even though the resource range is not declared IORESOURCE_BUSY, it still prevents mapping the i5400 FSB registers @ [mem 0xfe000000-0xfe01ffff]. dmesg, dmidecode, lspci, and /proc/iomem output attached.
Created attachment 85681 [details] dmidecode log
Created attachment 85691 [details] /proc/iomem
Created attachment 85701 [details] lspci log
No apparent problems when using "pci=nocrs".
Proposed patch to emit a diagnostic (but not an actual fix): http://lkml.kernel.org/r/1352343356-4006-5-git-send-email-peter@hurleysoftware.com More analysis (from Peter): > The adjacent resources (northbridge & southbridge) are not defined by > ACPI, but rather reserved with an e820 address descriptor from > [0xfe000000-0xfeffffff], so strictly speaking there is no overlapping > ACPI resource. > The e820 descriptor is bumped out to [0xf0000000-0xfeffffff] and the > malformed host bridge window is reparented to it. > At this point in the boot, there is no resource conflict. > Later in the boot, the i5k_amb driver tries to map > [0xfe000000-0xfe01ffff] which is the FB-DIMM AMB register window on the > Intel 5400 MCH and is rejected. The request is rejected because the > requested range does not map completely to a single parent and this is > not allowed. (The i5k_amb driver exposes the FB-DIMM temperature sensors > through sysfs). > There is no problem in Windows because no driver attempts to allocate > [0xfe000000-0xfe01ffff]. However, I doubt the PNP Manager would allow > another bus pdo to claim an overlapping resource with PCI bus 0. I > suspect the offending device would yellow bang. (That would be an > interesting experiment...) >> In the meantime (until we figure out how to handle overlapping >> resources better), can we do something to actually fix this? Maybe we >> should truncate the end of the range to 0xFDFFFFFF like we do for >> non-addressable parts of the range? > Auto-fixing this seems problematic because it's essentially impossible > to determine if the resource length or the resource end or both is > wrong.