Bug 54981

Created attachment 94961 [details]
v3.9-rc1 dmesg with "pcie_ports=native" (ExpressCard found)

Created attachment 94971 [details]
acpidump (raw, undecoded)

Created attachment 94981 [details]
DSDT.dsl (disassembled from acpidump)

Created attachment 95531 [details]
dmesg output showing ACPI debug when inserting Expresscard

Created attachment 95541 [details]
lspci -vv output

Created attachment 95551 [details]
Console log showing commands executed to capture diagnostics above

The attachments at comments 4, 5 and 6 were created on a kernel built from a fresh pull from Linus' tree this moring (v3.9-rc2-333-ge204378). The pcie hotplug driver is built in to the kernel. ACPI hotplug is not enabled.

I think this is an acpiphp bug.

On this machine, we should be using acpiphp for ExpressCard hotplug because the BIOS did not grant us permission to use native PCIe hotplug:

  \_SB_.PCI0:_OSC invalid UUID
  _OSC request data:1 8 1f 
  \_SB_.PCI0:_OSC invalid UUID
  _OSC request data:1 f 1f 
  acpi PNP0A08:00: ACPI _OSC support notification failed, disabling PCIe ASPM
  acpi PNP0A08:00: Unable to request _OSC control (_OSC support mask: 0x08)

We did supply a valid UUID, of course; _OSC returned the error because "NEXP" is not set:

  Method (_OSC, 4, Serialized) {
    ...
    If (LAnd (LEqual (Arg0, GUID), NEXP)) {
      ... # normal case
      If (And (CTRL, One)) {    # requesting PCIe native hotplug control?
        NHPG ()
      }
      ...
    } Else {
      Or (CDW1, 0x04, CDW1)     # "unrecognized UUID" error
      Return (Local0)
    }

NEXP is in the GNVS area (for communication between BIOS/ACPI/SMI) and is never set by AML.  I think it means "Native PCI Express," and is likely set by the BIOS on some other platform that shares this AML.  But it's not set in *this* case, so we shouldn't use PCIe native hotplug.

If the BIOS had granted permission to use PCIe native hotplug, the NHPG method:

  Method (NHPG, 0, Serialized) {
    Store (Zero, ^RP01.HPEX)
    ...

would clear the HPEX bits in each root port.  This is an Intel 6 Series/C200 Series chipset, and HPEX is the "Hot Plug SCI Enable" bit in the Miscellaneous Port Configuration register (spec sec 19.1.50) -- bit 30 in the 32-bit word at config space offset 0xd8.  When HPEX is set, an ACPI SCI is generated for hotplug events; when cleared, no SCI is generated.

In this case, the BIOS did not grant permission for PCIe native hotplug, and Chris's experiment (comments #4 and #6) showed that HPEX is set, so the chipset will generate an SCI, which means the platform expects us to use ACPI hotplug:

  [root:/home/chris]$ setpci -s 1c.3 0xd8.l
  c1118002

When Chris inserted the ExpressCard, we got a Bus Check notification on RP04, which means we should re-enumerate below 1c.3, which would discover the new device:

  evmisc-0169 [07] ev_queue_notify_reques: Dispatching Notify on [RP04] (Device) Value 0x00 (Bus Check) Node f3027eb8

However, acpiphp doesn't receive this notification because it thinks hotplug can only happen if we have the right combination of _ADR/_EJ0/_RMV methods, which we don't have in this case, so it doesn't register for notifications on RP04.  I think the acpiphp dependency on these methods is incorrect.  We should be paying attention to this notification even in the absence of _ADR/_EJ0/_RMV.

v3.12-rc1 contains many acpiphp updates, as well as fixes to the
code that decides whether to use acpiphp or pciehp.  Can you please
retest with v3.12-rc1 or later, attach the complete dmesg log,
and note whether this issue is resolved?

Thanks for the prompt, Bjorn. Hotplugging of my PCI Express usb3 is now working. This is using 3.12.0-rc1+ (v3.12-rc1-255-gdcb30e6) with the acpiphp driver configured in, the pciehp driver configured out and "pcie_ports=native", which I had to use in prior kernels, removed from the kernel command line. I'll attach the dmesg in a few moments. Great work! Thanks.

Created attachment 109001 [details]
dmesg log showing successful hotplug of a pci express card

Thanks for testing this, Chris.  I wish I could take credit for this, but Rafael and Neil Horman did all the work.

One additional thing, though -- most distros configure in both acpiphp and pciehp (both have to be compiled in statically now), and all systems *should* work with both compiled in.  If not, we still have some work to do.  Any chance you could test that kernel config, too?

No problem, Bjorn. You analysed the problem, but thanks go to Rafael and Neil too.

I've tested this with both acpiphp and pciehp built in to the kernel and that works fine too. I'll attach the dmesg log in a moment.

Created attachment 109051 [details]
dmesg log showing successful hotplug of an ExpressCard (acpiphp + pciehp)

Excellent, thanks Chris!  Closing this bug report as resolved.