Bug 92671
Summary: | Linux denies 64-bit non-pref BARs in 64-bit prefetchable space even though it's safe | ||
---|---|---|---|
Product: | Drivers | Reporter: | Daniel J Blueman (daniel) |
Component: | PCI | Assignee: | drivers_pci (drivers_pci) |
Status: | RESOLVED PATCH_ALREADY_AVAILABLE | ||
Severity: | normal | CC: | bjorn |
Priority: | P1 | ||
Hardware: | x86-64 | ||
OS: | Linux | ||
Kernel Version: | 3.19-rc7 | Subsystem: | |
Regression: | No | Bisected commit-id: | |
Attachments: |
PCI listing
kernel log showing BARs being inhibited PNP: Don't check for overlaps with unassigned PCI BARs PCI: Mark invalid BARs as unassigned PCI: Show driver, BAR#, and resource on pci_ioremap_bar() failure PCI: Fail pci_ioremap_bar() on unassigned resources Kernel messages for unpatched 4.0-rc4 Kernel messages for 4.0-rc4 w/ Bjorn's 4 patches and my BAR flag patch |
Description
Daniel J Blueman
2015-02-04 11:16:06 UTC
Created attachment 165831 [details]
kernel log showing BARs being inhibited
Created attachment 170041 [details]
PNP: Don't check for overlaps with unassigned PCI BARs
This isn't a fix by itself, but it should get rid of some of the annoying messages like:
pnp 00:00: disabling [io 0x0061] because it overlaps 0001:05:00.0 BAR 0 [io 0x0000-0x00ff]
This message is incorrect because the PCI BAR 0 should be marked unassigned. If it were, we wouldn't enable it, so it couldn't conflict with anything.
Created attachment 170051 [details]
PCI: Mark invalid BARs as unassigned
Created attachment 170061 [details]
PCI: Show driver, BAR#, and resource on pci_ioremap_bar() failure
Created attachment 170071 [details]
PCI: Fail pci_ioremap_bar() on unassigned resources
Daniel, can you try the patches in comments #2-5 (in that order)? They won't help assign resources, but we should fail gracefully instead of dereferencing a null pointer. Many thanks for the patches; I booted 4.0-rc4 with the last four, and no change. It looks like the test for the BAR being unset is too late. The "Disabling ... because if overlaps ..." messages do go if I add: --- a/drivers/pci/probe.c +++ b/drivers/pci/probe.c @@ -281,6 +281,13 @@ int __pci_read_base(struct pci_dev *dev, enum pci_bar_type type, pcibios_resource_to_bus(dev->bus, &inverted_region, res); /* + * If firmware doesn't assign a valid PCI address (as legacy IO is below + * PCI IO), mark resource unset to prevent later resource conflicts + */ + if (region.start == 0) + res->flags |= IORESOURCE_UNSET; + + /* * If "A" is a BAR value (a bus address), "bus_to_resource(A)" is * the corresponding resource address (the physical address used by * the CPU. Converting that resource address back to a bus address I'll attach the dmesg boot output in the unpatched, and with you 4 four patches and this patch. Created attachment 171381 [details]
Kernel messages for unpatched 4.0-rc4
Created attachment 171391 [details]
Kernel messages for 4.0-rc4 w/ Bjorn's 4 patches and my BAR flag patch
Bjorn's patches landed in mainline a bit ago, so help the unexpected conflicts. Yinghai added support 64-bit non-prefetchable BARs in 64-bit prefetchable space in patch 34 of: https://groups.google.com/forum/?fromgroups#!topic/linux.kernel/AieDDCG3JcM |