> On Friday 26 September 2008, Bjorn Helgaas wrote:
> >
http://bugzilla.kernel.org/show_bug.cgi?id=11550
>
> Sorry for having to revive this old thread. In November 2008 I reported
> that this issue had been solved for me as a result of 1f98757776ea, but I
> now find that was due to faulty testing. (I suspect that changing the BIOS
> setting that affects this issue on my Toshiba laptop only takes effect
> after a cold boot, not a normal reboot.)
>
> The problem was that with the BIOS setting for "Device config" set to
> "Setup by OS", I get 78 messages like:
> pnp 00:08: io resource (0x2e-0x2f) overlaps 0000:00:1f.5 BAR 0 (0x0-0xff), disabling
> pnp 00:08: io resource (0x2e-0x2f) overlaps 0000:00:1f.6 BAR 0 (0x0-0xff), disabling
>
> If the BIOS setting is set to "All Devices", the problem does not occur.
>
> The origin of these messages was bisected to:
> commit aee3ad815dd291a7193ab01da0f1a30c84d00061
> Author: Bjorn Helgaas <bjorn.helgaas@hp.com>
> Date: Fri Jun 27 16:56:57 2008 -0600
> PNP: replace pnp_resource_table with dynamically allocated resources
>
> Last analysis from Bjorn was:
> > The problem seems to be that Frans has some PCI devices that are not
> > configured by the BIOS, and their BARs contain zero. A PNP quirk
> > checks for overlaps of PCI devices and PNP devices, and those zero-
> > valued BARs of course conflict with the PNP motherboard devices that
> > describe legacy hardware.
> >
> > Here's another approach based on section 3.5 of the PCI Firmware spec.
> > It says:
> >
> > Since not all devices may be configured prior to the operating
> > system handoff, the operating system needs to know whether a
> > specific BAR register has been configured by firmware. The operating
> > system makes the determination by checking the I/O Enable, and
> > Memory Enable bits in the device's command register, and Expansion
> > ROM BAR enable bits. If the enable bit is set, then the corresponding
> > resource register has been configured.
> >
> > So instead of checking whether the BAR contains zero, the patch below
> > checks the I/O, Mem, and ROM BAR enable bits to determine whether a
> > BAR is enabled.
>
> Below the then proposed patch from Bjorn, rediffed against 2.6.29-rc7.
> I've verified that the patch still solves the issue for me. Attached
> dmesg output for 2.6.29-rc7 without and with the patch.
>
> Bjorn, could you please consider this patch for inclusion again?
>
> Original thread:
http://marc.info/?l=linux-kernel&m=122095745403793&w=4