Hi Bill and Bjorn, Device 8086:0103 is "2nd Generation Core Processor Family Thermal Management Controller" or "Sandy Bridge Thermal Management Controller". And address range 0xfed98000-0xfed9ffff has been reserved by motherboard device(PNP0C02). I guess that BIOS has assigned address "0xfed98000" to 0000:00:04.0 for thermal management functionality. The BAR0 of 0000:00:04.0 may be locked down (can't be changed by OS) because the ACPI BIOS may have dependency on the assigned address ranges. A ACPI dump may give some help here if convenient. Thanks! Gerry On 06/02/2012 12:22 AM, Bill Unruh wrote: > Attached is a complete dmesg from a bootup of the kernel on the toughbook S10. > > > RE the noapic, I have no idea how I can give more information on it, since the > crash almost always occurs during the boot process itself, often very early in > the process. I will see if I can resurect the dmesg that gets saved, if any, > during that process. It is probably also an earlier kernel. I have not dared > try my current kernel with noapic, but perhaps I will try. > > > > On Fri, 1 Jun 2012, Bjorn Helgaas wrote: > >> On Thu, May 31, 2012 at 3:39 PM, Bill Unruh <unruh@xxxxxxxxxxxxxx> wrote: >>> I am running Mageia 2 kernel 3.3.6-desktop586-2.mga2 >>> >>> Every time I boot up I get the error messages >>> pci 0000:00:04.0: BAR 0: error updating (0xdfa00004 != 0xfed98004) >> >> Thanks very much for this report. I opened this bug report to help me >> keep track of it: https://bugzilla.kernel.org/show_bug.cgi?id=43331 >> >> The message means that we tried to write address 0xdfa00000 to BAR 0 >> of device 00:04.0 (a "signal processing controller," whatever that >> is), but when we read the BAR back, we read 0xfed98004 instead. >> That's an interesting address because it looks a lot like a resource >> of an ACPI PNP0c02 device: >> >> system 00:0e: [mem 0xfed98000-0xfed9ffff] has been reserved >> system 00:0e: Plug and Play ACPI device, IDs PNP0c02 (active) >> >> You say your machine runs OK (with "noapic"), but I'm doubtful that >> 00:04.0 is working -- it doesn't even seem to have a driver bound to >> it. I don't know what the device does, but if you're not using it, >> it's not surprising that you wouldn't notice it being broken. >> >> Can you attach the complete dmesg log to the bugzilla? It will have >> more details about other devices and the ranges from which we allocate >> resources for PCI devices. >> >> You mention that the machine is not reliable unless you use "noapic". >> That sounds like a separate bug, but also something it would be good >> to track down. >> > -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
