Created attachment 94951 [details] v3.9-rc1 dmesg (ExpressCard not found) Chris Clayton reported (see URL above) that on this machine: DMI: FUJITSU LIFEBOOK AH531/FJNBB0F, BIOS 1.30 05/28/2012 hotplug doesn't work at all. An ExpressCard is only recognized if it is present at boot (or by writing 1 to /sys/bus/pci/rescan). Hotplug fails even when both pciehp and acpiphp are build in statically. We use _OSC to ask the BIOS to give us control of native PCIe services. It fails with "unrecognized UUID", so pciehp (the native PCIe hotplug driver) is disabled. With "pcie_ports=native", we still use _OSC, and it still fails, but we go ahead and use pciehp even though the BIOS didn't give us permission. In this case, pciehp does work, and it recognizes insertion of the ExpressCard [1]. I don't see any _EJ0 or _RMV methods in the ACPI namespace, so I don't think acpiphp will work, so native PCIe hotplug must be the intended strategy on this system. The _OSC method fails because it contains this: Method (_OSC, 4, Serialized) { ... If (LAnd (LEqual (Arg0, GUID), NEXP)) ... # normal case Else { Or (CDW1, 0x04, CDW1) # "unrecognized UUID" error Return (Local0) } and "NEXP" is apparently false. NEXP is not set anywhere in the DSDT. [1] http://lkml.kernel.org/r/51065FA6.4070208@googlemail.com
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.