Re: [Bug 43331] Re: Bug on bootup of Linux kernel on Panasonic ToughbookS10

[Jiang Liu]

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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/