linux-kernel - Re: [Bug 43331] Re: Bug on bootup of Linux kernel on Panasonic Toughbook S10

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.64.1206010915580.26561@info>
Date:	Fri, 1 Jun 2012 09:22:30 -0700 (PDT)
From:	Bill Unruh <unruh@...sics.ubc.ca>
To:	Bjorn Helgaas <bhelgaas@...gle.com>
cc:	linux-kernel@...r.kernel.org, linux-pci@...r.kernel.org,
	bugzilla-daemon@...zilla.kernel.org
Subject: Re: [Bug 43331] Re: Bug on bootup of Linux kernel on Panasonic
 Toughbook S10

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@...sics.ubc.ca> 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.
>

-- 
William G. Unruh   |  Canadian Institute for|     Tel: +1(604)822-3273
Physics&Astronomy  |     Advanced Research  |     Fax: +1(604)822-5324
UBC, Vancouver,BC  |   Program in Cosmology |     unruh@...sics.ubc.ca
Canada V6T 1Z1     |      and Gravity       |  www.theory.physics.ubc.ca/
View attachment "dmesg" of type "TEXT/PLAIN" (70339 bytes)