[opensuse-kernel] pciehp (epresscard) not working on 3.11rc4 anymore
Hi all, with 3.11rc4, an USB 3.0 expresscard is not working anymore in my ThinkPad X200s unless it is plugged at boot. I'm not 100% sure when it last worked, but in the logs I see that I used it with 3.10rc4. One difference between 3.11-suse and 3.10-suse is, that pciehp is now built in. In 3.10 I had to load it manually to get the card to work. So I'm wondering if there is just some parameter I need to set or if there is a way to trigger the "rescanning" of the port. I don't get any interrupts when inserting or ejecting the card: susi:~ # grep PCIe /proc/interrupts 40: 0 0 PCI-MSI-edge PCIe PME, pciehp 41: 0 0 PCI-MSI-edge PCIe PME, pciehp 42: 0 0 PCI-MSI-edge PCIe PME Any hints? Best regards, Stefan -- Stefan Seyfried "If your lighter runs out of fluid or flint and stops making fire, and you can't be bothered to figure out about lighter fluid or flint, that is not Zippo's fault." -- bkw -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
Hi all, Am 10.08.2013 12:24, schrieb Stefan Seyfried:
Hi all,
with 3.11rc4, an USB 3.0 expresscard is not working anymore in my ThinkPad X200s unless it is plugged at boot.
lame self-reply :-) the following message on boot cleared it up: pci_hotplug: PCI Hot Plug PCI Core version: 0.5 pciehp 0000:00:1c.0:pcie04: HPC vendor_id 8086 device_id 2940 ss_vid 17aa ss_did 20f3 pciehp 0000:00:1c.0:pcie04: service driver pciehp loaded pciehp 0000:00:1c.1:pcie04: HPC vendor_id 8086 device_id 2942 ss_vid 17aa ss_did 20f3 pciehp 0000:00:1c.1:pcie04: service driver pciehp loaded pciehp 0000:00:1c.3:pcie04: HPC vendor_id 8086 device_id 2946 ss_vid 17aa ss_did 20f3 pciehp 0000:00:1c.3:pcie04: pci_hp_register failed with error -16 pciehp 0000:00:1c.3:pcie04: Slot already registered by another hotplug driver pciehp: PCI Express Hot Plug Controller Driver version: 0.4 I checked with old logs and found, that device 1c.3 is obviously the one that has the expresscard slot connected: [62934.094971] pci_hotplug: PCI Hot Plug PCI Core version: 0.5 [62934.095493] pciehp 0000:00:1c.0:pcie04: HPC vendor_id 8086 device_id 2940 ss_vid 17aa ss_did 20f3 [62934.095547] pciehp 0000:00:1c.0:pcie04: service driver pciehp loaded [62934.095565] pciehp 0000:00:1c.1:pcie04: HPC vendor_id 8086 device_id 2942 ss_vid 17aa ss_did 20f3 [62934.095604] pciehp 0000:00:1c.1:pcie04: service driver pciehp loaded [62934.095619] pciehp 0000:00:1c.3:pcie04: HPC vendor_id 8086 device_id 2946 ss_vid 17aa ss_did 20f3 [62934.095658] pciehp 0000:00:1c.3:pcie04: service driver pciehp loaded [62934.095669] pciehp: PCI Express Hot Plug Controller Driver version: 0.4 [62938.401428] pciehp 0000:00:1c.3:pcie04: Card present on Slot(3) [62938.513109] pci 0000:05:00.0: [1b73:1000] type 00 class 0x0c0330 (this was from June 19, 3.10rc6) Investigating, I found out that acpiphp is now claiming the device, effectively keeping pciehp from working. boot parameter "acpiphp.disable=1" makes everything work fine. So a few questions: * should this also work with acpiphp? * if not, should the machine be blacklisted in acpiphp? * is this maybe a configuration error on the SUSE kernel? e.g. "acpiphp and pciehp should not be both enabled"? If it is not a SUSE kernel problem, I can take it upstream. Thanks for any hints and insights. Stefan -- Stefan Seyfried "If your lighter runs out of fluid or flint and stops making fire, and you can't be bothered to figure out about lighter fluid or flint, that is not Zippo's fault." -- bkw -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Sat, 2013-08-10 at 12:49 +0200, Stefan Seyfried wrote:
* should this also work with acpiphp?
If acpiphp claims the slot it should work.
* if not, should the machine be blacklisted in acpiphp?
Preferably the bug should be fixed.
* is this maybe a configuration error on the SUSE kernel? e.g. "acpiphp and pciehp should not be both enabled"?
No. We have seen machines which need both. Regards Oliver -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Sat, Aug 10, 2013 at 12:49:41PM +0200, Stefan Seyfried wrote:
Hi all,
Am 10.08.2013 12:24, schrieb Stefan Seyfried:
Hi all,
with 3.11rc4, an USB 3.0 expresscard is not working anymore in my ThinkPad X200s unless it is plugged at boot.
lame self-reply :-)
the following message on boot cleared it up:
pci_hotplug: PCI Hot Plug PCI Core version: 0.5 pciehp 0000:00:1c.0:pcie04: HPC vendor_id 8086 device_id 2940 ss_vid 17aa ss_did 20f3 pciehp 0000:00:1c.0:pcie04: service driver pciehp loaded pciehp 0000:00:1c.1:pcie04: HPC vendor_id 8086 device_id 2942 ss_vid 17aa ss_did 20f3 pciehp 0000:00:1c.1:pcie04: service driver pciehp loaded pciehp 0000:00:1c.3:pcie04: HPC vendor_id 8086 device_id 2946 ss_vid 17aa ss_did 20f3 pciehp 0000:00:1c.3:pcie04: pci_hp_register failed with error -16 pciehp 0000:00:1c.3:pcie04: Slot already registered by another hotplug driver pciehp: PCI Express Hot Plug Controller Driver version: 0.4
I checked with old logs and found, that device 1c.3 is obviously the one that has the expresscard slot connected:
[62934.094971] pci_hotplug: PCI Hot Plug PCI Core version: 0.5 [62934.095493] pciehp 0000:00:1c.0:pcie04: HPC vendor_id 8086 device_id 2940 ss_vid 17aa ss_did 20f3 [62934.095547] pciehp 0000:00:1c.0:pcie04: service driver pciehp loaded [62934.095565] pciehp 0000:00:1c.1:pcie04: HPC vendor_id 8086 device_id 2942 ss_vid 17aa ss_did 20f3 [62934.095604] pciehp 0000:00:1c.1:pcie04: service driver pciehp loaded [62934.095619] pciehp 0000:00:1c.3:pcie04: HPC vendor_id 8086 device_id 2946 ss_vid 17aa ss_did 20f3 [62934.095658] pciehp 0000:00:1c.3:pcie04: service driver pciehp loaded [62934.095669] pciehp: PCI Express Hot Plug Controller Driver version: 0.4 [62938.401428] pciehp 0000:00:1c.3:pcie04: Card present on Slot(3) [62938.513109] pci 0000:05:00.0: [1b73:1000] type 00 class 0x0c0330
(this was from June 19, 3.10rc6)
Investigating, I found out that acpiphp is now claiming the device, effectively keeping pciehp from working.
boot parameter "acpiphp.disable=1" makes everything work fine.
So a few questions:
* should this also work with acpiphp? * if not, should the machine be blacklisted in acpiphp? * is this maybe a configuration error on the SUSE kernel? e.g. "acpiphp and pciehp should not be both enabled"?
If it is not a SUSE kernel problem, I can take it upstream.
Please let upstream know about this on the linux-pci@vger.kernel.org mailing list. It's what some of us worried about when this change was made :( thanks, greg k-h -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
Am 10.08.2013 20:59, schrieb Greg KH:
On Sat, Aug 10, 2013 at 12:49:41PM +0200, Stefan Seyfried wrote:
If it is not a SUSE kernel problem, I can take it upstream.
Please let upstream know about this on the linux-pci@vger.kernel.org mailing list.
Ok, following up there.
It's what some of us worried about when this change was made :(
Well, it also did not work "out of the box" before, since I always had to load pciehp manually. Probably if I had tried acpiphp, it would not have worked before as well :-) And as I found a workaround, it is not a grave bug, but of course it's better to have it fixed. best regards, Stefan -- Stefan Seyfried "If your lighter runs out of fluid or flint and stops making fire, and you can't be bothered to figure out about lighter fluid or flint, that is not Zippo's fault." -- bkw -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
participants (3)
-
Greg KH -
Oliver Neukum -
Stefan Seyfried