Created attachment 749130 [details] dmesg Description of problem: Message on startup pci_hp_register failed with error -16 Version-Release number of selected component (if applicable): kernel 3.10.0-0.rc1.git5.1.fc20.x86_64 How reproducible: Always. Steps to Reproduce: Boot the system. Actual results: pci_hp_register failed with error -16 Unable to test ExpressCard/34 port, but search yields for others with this error message, their ExpressCard/34 port doesn't work. Expected results: Not this error. Additional info: Error doesn't occur with kernel .9.2-301.fc19.x86_64
I'm also having same problem. Kernel Version : 3.10.5-201.fc19.x86_64 Fedora version : 19 Hardware : HP probook 4230s
I have this problem too, it's quite annoying. OS: Fedora 19 Kernel: 3.10.5-201.fc19.x86_64 Hardware: HP ProBook 4530s
Same here. kernel: 3.10.6-200.fc19.x86_64 hardware: HP EliteBook 8560w (LG661EA) [root@hamburger ~]# dmesg | grep -i pciehp [ 2.367066] pciehp 0000:00:1c.1:pcie04: HPC vendor_id 8086 device_id 1c12 ss_vid 103c ss_did 1631 [ 2.367090] pciehp 0000:00:1c.1:pcie04: pci_hp_register failed with error -16 [ 2.367177] pciehp 0000:00:1c.1:pcie04: Slot already registered by another hotplug driver [ 2.367186] pciehp: PCI Express Hot Plug Controller Driver version: 0.4 The first few kernels for f19 did not have this issue. It only showed up after a recent kernel update.
Exactly the same as Richard Allen newer kernel: 3.10.7-200.fc19.x86_64 hardware: HP Probook 4320s [ 0.892243] pciehp 0000:00:1c.1:pcie04: HPC vendor_id 8086 device_id 3b44 ss_vid 103c ss_did 1423 [ 0.892258] pciehp 0000:00:1c.1:pcie04: pci_hp_register failed with error -16 [ 0.892327] pciehp 0000:00:1c.1:pcie04: Slot already registered by another hotplug driver [ 0.892343] pciehp 0000:00:1c.5:pcie04: HPC vendor_id 8086 device_id 3b4c ss_vid 103c ss_did 1423 [ 0.892354] pciehp 0000:00:1c.5:pcie04: pci_hp_register failed with error -16 [ 0.892420] pciehp 0000:00:1c.5:pcie04: Slot already registered by another hotplug driver [ 0.892426] pciehp: PCI Express Hot Plug Controller Driver version: 0.4
I'm tracking this in bz 990078 currently. Its currently a private bugzilla but I'll put any relevant information about the bug in here. FWIW, its not currently a major issue, in that it just means that the slots in question will use acpi to detect hotplug events rather than the pcie hotplug hardware. If you want to fix it up, you should be able to do so by either disabling acpi on the system using the acpi=off kernel command line parameter or by telling pcie to use acpi to detect hotplug capabilities (via the pciehp.pciehp_detectmode=acpi kernel command line parameter).
So why would this be happening on non-HP hardware? Specifically Apple hardware? That's the hardware in the dmesg attached.
Because the problem isnt restricted to hp hardware. hp in this case doesn't stand for Hewlett Packard. It stands for Hot Plug. The ACPI tables are listing pcie slots as being serviced by the acpi hotplug mechanism on these systems, but the pcie bridge has its own hot plug system. As a result both controllers are attempting to run hot plug on the slots being reported. Its not actually a problem, the error is just indicating that acpi registered first and handles hotplug for that slot (the pcie controller is reporting that hot plug is already registered for said slot). You work around it by telling pcie to use acpi for hotplug, or by disabling acpi, so pcie can control the slot. the long term fix for this I think will be to only issue the warning, if pcie hotplug control was asserted via the pciehp_detectmode=pcie command line parameter.
Thanks for the update. Is it ideal for the hot plug slots to be managed by ACPI, or the PCIe bridge? Or is this best answered through testing?
Its going to depend on your system. Ideally the system should have decided for you (by virtue of the fact that hot plug capable pcie slots should not be enumerated by the BIOS provided ACPI hotplug tables, meaning only one subsystem would claim each slot). So technically your BIOS is a little broken here, although its really a minor issue. I imagien for pcie slots, pcie would be the preferable hot plug mechhanism. but since you can't exclude ports from acpi control, just turn it off entirely, the need for some other acpi component (perhaps laptop lid buttons, or power management), may require that you use acpi here.
(In reply to Neil Horman from comment #9) Firmware is based on the (old) Intel EFI 1.10 spec, before UEFI, with Apple flavoring, which BTW their current hardware also still use. And it's a laptop so I'm not sure they anticipate users actually opening it up and hot swapping the one and only drive.
That may well be, but the OS isn't going to differentiate intent link that. It sees pcie slots with hotplug capabilities and an ACPI table from the system firmware that says it has hotplug enabled ports, its going to try to setup hotplug. If you don't want to use hotplug, you either turn off hotplug features (acpi=off, pcie_ports=compat). Or you can root around in your firmware config to disable hotplug support from there, or alternatively, you recognize the errors are a benign results of conflicting hotplug services and ignore them, since you know your not going to use hotplug anyway.
So interesting findings. I don't think I'll need to modify the printks at all. In trying to figure out a simmilar related bug, I found that acpi should be checking the pcie hotplug capabilities first, but it was doing so before the acpi code itself populated the flags variable used to determine pcie support. As a result we were trying to register 2 hotplug controllers where only one should ever be registered. I've sent a patch upstream here: https://lkml.org/lkml/2013/8/23/379 For review, if you want to try it out, it should suppress your errors, and select the right hot plug controller for your systems (which should typically be pcie I think).
I have this problem too, on a Lenovo X200s with fedora 18 (3.10.9-100.fc18.x86_64 #1 SMP Wed Aug 21 18:25:04 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux). In my case, the error is shown when trying to restore the system after sleep: at this point, nothing can be done (cursor is shown but doesn't move, keys have no effect) and the only option is to reboot. dmesg after reboot: [ 1.037119] io scheduler noop registered [ 1.037121] io scheduler deadline registered [ 1.037157] io scheduler cfq registered (default) [ 1.037315] pcieport 0000:00:1c.0: irq 40 for MSI/MSI-X [ 1.037446] pcieport 0000:00:1c.1: irq 41 for MSI/MSI-X [ 1.037577] pcieport 0000:00:1c.3: irq 42 for MSI/MSI-X [ 1.037718] pcieport 0000:00:1c.0: Signaling PME through PCIe PME interrupt [ 1.037724] pcie_pme 0000:00:1c.0:pcie01: service driver pcie_pme loaded [ 1.037746] pcieport 0000:00:1c.1: Signaling PME through PCIe PME interrupt [ 1.037749] pci 0000:03:00.0: Signaling PME through PCIe PME interrupt [ 1.037754] pcie_pme 0000:00:1c.1:pcie01: service driver pcie_pme loaded [ 1.037778] pcieport 0000:00:1c.3: Signaling PME through PCIe PME interrupt [ 1.037784] pcie_pme 0000:00:1c.3:pcie01: service driver pcie_pme loaded [ 1.037800] pci_hotplug: PCI Hot Plug PCI Core version: 0.5 [ 1.037874] pciehp 0000:00:1c.0:pcie04: HPC vendor_id 8086 device_id 2940 ss_vid 17aa ss_did 20f3 [ 1.037911] pciehp 0000:00:1c.0:pcie04: service driver pciehp loaded [ 1.037925] pciehp 0000:00:1c.1:pcie04: HPC vendor_id 8086 device_id 2942 ss_vid 17aa ss_did 20f3 [ 1.037957] pciehp 0000:00:1c.1:pcie04: service driver pciehp loaded [ 1.037972] pciehp 0000:00:1c.3:pcie04: HPC vendor_id 8086 device_id 2946 ss_vid 17aa ss_did 20f3 [ 1.037984] pciehp 0000:00:1c.3:pcie04: pci_hp_register failed with error -16 [ 1.037991] pciehp 0000:00:1c.3:pcie04: Slot already registered by another hotplug driver [ 1.038013] pciehp: PCI Express Hot Plug Controller Driver version: 0.4
(In reply to Neil Horman from comment #5) > If you want to fix it up, you should be able to do so by either > disabling acpi on the system using the acpi=off kernel command line > parameter or by telling pcie to use acpi to detect hotplug capabilities (via > the pciehp.pciehp_detectmode=acpi kernel command line parameter). I was also getting this issue with my HP EliteBook 8460p I tried adding pciehp.pciehp_detectmode=acpi to the kernel line, but that did not resolve the error I was getting. Looks like disabling acpi was the only way to avoid the error on my end.
(In reply to Neil Horman from comment #5) > If you want to fix it up, you should be able to do so by either > disabling acpi on the system using the acpi=off kernel command line > parameter or by telling pcie to use acpi to detect hotplug capabilities (via > the pciehp.pciehp_detectmode=acpi kernel command line parameter). I was also getting this issue with my HP EliteBook 8460p I tried adding pciehp.pciehp_detectmode=acpi to the kernel line, but that did not resolve the error I was getting. Looks like disabling acpi was the only way to avoid the error on my end, which caused some other issues with powermanagement on my machine. From what I could tell from the email thread in the link, it sounded like this will be fixed with changes in kernel 3.12
yeah, the fix is in linus' tree now (commit 3dc48af310709b85d07c8b0d3aa8f1ead02829d3). i"ll backport it shortly.
kernel-3.11.1-300.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/kernel-3.11.1-300.fc20
Package kernel-3.11.1-300.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing kernel-3.11.1-300.fc20' as soon as you are able to, then reboot. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-16794/kernel-3.11.1-300.fc20 then log in and leave karma (feedback).
kernel-3.11.1-200.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/kernel-3.11.1-200.fc19
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 19 kernel bugs. Fedora 19 has now been rebased to 3.11.1-200.fc19. Please test this kernel update and let us know if you issue has been resolved or if it is still present with the newer kernel. If you experience different issues, please open a new bug report for those.
kernel-3.11.1-200.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
kernel-3.11.1-300.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.