Cc-ing the public Linux PCI and USB mailing lists. On Fri, Apr 12, 2013 at 02:59:29PM -0400, Bulkow, David wrote: > Susan, I'm Sarah. :) > While testing Linux 3.9 we ran into an issue which I believe is a > conflict between a couple of PCI changes. Stratus has hardware that > can hot add/remove chunks of its PCI hierarchy which has tickled some > of the newer code. I am mailing you because I believe the second > change I list below holds the key. > > I believe we are experiencing a collision between two changes. The > first: > > PCI: Put pci_dev in device tree as early as possible > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=4f535093cf8f6da8cfda7c36c2c1ecd2e9586ee4 > > is causing device_add to be called during pci_scan_slot. The second: > > USB: Fix handoff when BIOS disables host PCI device > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=cab928ee1f221c9cc48d6615070fefe2e444384a > > is getting activated by device_add. So this system includes a Panther Point or Lynx Point xHCI host? I'm running 3.9-rc6 with a Panther Point xHCI host, and it works fine, so this is probably related to hot-plug, or perhaps a hardware-specific issue. > We are seeing complaints during pci_scan_slot like "BIOS handoff > failed", "device not available... can't reserve IO" or mem for all USB > devices. Furthermore we are seeing the enable_cnt <= 0 warning, > "disabling already-disabled device" in pci_disable_device during > subsequent bringdown (or hot remove) operations. We are using the > protocol pci_scan_slot -> <assign IO/mem resources> -> > pci_add_bus_resources to hot-add devices after they have been > initialized. I believe the first set of messages are because we have > not yet assigned resources, but to do so the pci devices must be > established - in pci_scan_slot. The disable message is happening > because the first failures during pci_scan_slot are over-decrementing > enable_cnt in pci_enable_device_flags when do_pci_enable_device fails. What are your BIOS settings for xHCI? Some BIOSes have an option to disable the xHCI host. In that case, the BIOS won't respond to the xHCI BIOS/OS handoff, and the xHCI PCI register that tells Linux which ports are available to switch over from EHCI to xHCI will be all zeroes (meaning we can't switch any ports over). Originally, there was some talk of having the BIOS hide the PCI device from the OS if the xHCI host was disabled in the BIOS. I wonder if some non-Intel BIOS vendor did that. > What caught my eye in the second change, in usb quirk code, is that it > does not differentiate between boot mode or hot-add operation. It is > certainly possible we are doing PCI add incorrectly - things are > moving quickly right now. I don't understand why it should matter whether that code is run directly after boot or on hot-add. All that code does is read and write the PCI MMIO registers, which should be available when the quirk is called. > Would you mind taking a look and correcting my understanding? As for the other warnings, I think the PCI maintainer (Bjorn) is going to have to address those, as I'm not a PCI expert. Sarah Sharp -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
