Bug 14337

Summary: PCI host bridge driver accepts invalid apertures
Product: Drivers Reporter: Bjorn Helgaas (bjorn.helgaas)
Component: PCIAssignee: drivers_pci (drivers_pci)
Status: CLOSED CODE_FIX    
Severity: normal CC: acpi-bugzilla, jbarnes, lenb, yakui.zhao
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 2.6.32-rc3 Subsystem:
Regression: No Bisected commit-id:
Attachments: PCI resources from Windows device manager
Windows with a non-aligned IO window

Description Bjorn Helgaas 2009-10-06 22:42:29 UTC 
On x86, we currently ignore PCI host bridge _CRS by default, but booting with "pci=use_crs" on an HP DL360 G3, BIOS version P31 10/31/2003, ACPI reports these windows in a PCI host bridge _CRS:

  pci_root PNP0A03:00: host bridge window: [io  0x0000-0x0cff]
  pci_root PNP0A03:00: host bridge window: [io  0x0000-0x2cfe]
  pci_root PNP0A03:00: host bridge window: [io  0x03b0-0x03bb]
  pci_root PNP0A03:00: host bridge window: [io  0x03c0-0x03df]
  pci_root PNP0A03:00: host bridge window: [mem 0xf5d00000-0xf6ffffff]
  pci_root PNP0A03:00: host bridge window: [mem 0x000a0000-0x000bffff]

The bridge has this device behind it:

  pci 0000:00:05.2: reg 10: [io  0x2c00-0x2cff]

This device BAR (0x2c00-0x2cff) doesn't fit in the bridge aperture (0x0-0x2cfe).  This leads to the following allocation failure and causes PNP to mistakenly detect a conflict between a motherboard device and the BAR:

  pci 0000:00:05.2: BAR 0: no parent found for device [io  0x2c00-0x2cff]
  pci 0000:00:05.2: BAR 0: can't allocate [io  0x2c00-0x2cff]
  pnp 00:01: resource [io  0x0092] overlaps 0000:00:05.2 BAR 0 [io  0x0000-0x00ff], disabling
  pnp 00:01: resource [io  0x0010-0x001f] overlaps 0000:00:05.2 BAR 0 [io  0x0000-0x00ff], disabling

I think the host bridge aperture size reported by _CRS (0x2cff) is invalid.  The low two bits of PCI I/O BARs are not part of the base address, so I/O decoders must be aligned on four-byte boundaries, and they must be a multiple of four bytes in size.

I installed Windows Server 2003 SP1 on this system.  The attached Device Manager screenshot shows that Windows rounded the size up to a multiple of four.

This is pretty clearly a BIOS bug, but it would be straightforward to work around it in Linux.
Comment 1 Bjorn Helgaas 2009-10-06 22:44:33 UTC 
Created attachment 23292 [details]
PCI resources from Windows device manager
Comment 2 ykzhao 2009-10-13 00:50:32 UTC 
Hi, Bjorn
    Will you please add the boot option of "pci=earlydump" and attach the output of dmesg?
   Please also attach the output of acpidump, lspci -vxxx.
   Thanks.
Comment 3 Len Brown 2009-11-06 03:36:47 UTC 
Patch from Bjorn:
http://patchwork.kernel.org/patch/57712/
Comment 4 Bjorn Helgaas 2010-04-27 18:49:32 UTC 
Here's part of the _CRS descriptor dump for the [io  0x0000-0x2cfe] window above:

    [02] 16-Bit WORD Address Space Resource
              Resource Type : I/O Range
            Address Minimum : 0000  (_MIN)
            Address Maximum : 2CFF  (_MAX)
             Address Length : 2CFF  (_LEN)

Windows computed the window as [io  0x0000-0x2cff] instead.  I assumed this was because Windows was rounding the end to a sensible boundary.  But I now think Windows is ignoring _LEN and simply using [_MIN to _MAX].
Comment 5 Bjorn Helgaas 2010-04-27 18:55:49 UTC 
Created attachment 26162 [details]
Windows with a non-aligned IO window

Here's a Windows screenshot showing an I/O window where [_MIN to _MIN + _LEN - 1] would be [io  0x0d00-0xffff], but Windows is apparently using [_MIN to _MAX], or [io  0xd00-0xfffe].

Doing the same in Linux would make the code simpler and (I hope) closer to what Windows does.
Comment 6 Len Brown 2010-04-29 01:52:08 UTC 
bjorn's two patches on this subject:

https://patchwork.kernel.org/patch/95495/
https://patchwork.kernel.org/patch/95493/

applied to acpi test tree
Comment 7 Jesse Barnes 2010-04-29 15:51:06 UTC 
Already pulled the x86/PCI patch into my tree and sent to Linus yesterday.
Comment 8 Len Brown 2010-05-20 02:57:20 UTC 
shipped in 2.6.34
closed