linux-kernel - [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: <CAErSpo7p6XGmsi0Q0PAbWofs9-91taz2Px=VxzL2KEoWWYJwSA@mail.gmail.com>
Date:	Fri, 1 Jun 2012 09:47:28 -0600
From:	Bjorn Helgaas <bhelgaas@...gle.com>
To:	Bill Unruh <unruh@...sics.ubc.ca>
Cc:	linux-kernel@...r.kernel.org, linux-pci@...r.kernel.org,
	bugzilla-daemon@...zilla.kernel.org
Subject: [Bug 43331] Re: Bug on bootup of Linux kernel on Panasonic Toughbook S10

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.
--
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/