Bug 43192
|
Description
Elmar Stellnberger
2012-05-02 12:15:12 UTC
The ExpressCard interface (Amilo Xi2550, AdapterNo: 07473DD) works well if you boot coldplugged. See the lspci -vv listings for kernel 3.4.6-1.1: Created attachment 82571 [details]
booting coldplugged
Created attachment 82581 [details]
unplugged after boot
Created attachment 82591 [details]
(re-)hotplugging (after coldboot)
If I re-plug the expresscard (hotplug) the flags recognized by lspci -vv are different and the card does not work.
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? Created attachment 120501 [details]
messages extract from plugging in UBS3.0 ExpressCard via PCMCIA adapter
The card is recognized at least via the PCMCIA-Express card adapter now; however it does not recognize any plug-in and plug-out events of individual USB devices (tested with mouse and an USB-stick); tested with 3.13.0-rc6-4-default, i686.
Created attachment 120511 [details]
lspci -vvv from plugging in UBS3.0 ExpressCard via PCMCIA adapter (3.13.0-rc6-4-default, i686)
Created attachment 120521 [details]
lspci -vvv, everything unplugged (3.13.0-rc6-4-default, i686)
Created attachment 120531 [details]
/proc/interrupts before plugging in an USB stick
Created attachment 120541 [details]
/proc/interrupts after plugging in an USB stick
Created attachment 120551 [details]
/var/log/messages excerpt with vmlinuz-3.11.6-4-debug
perhaps also a kernel configured for debugging would help (here we have an elder version of such a kernel).
Thanks, Elmar. Seems like we might be making progress -- at least we recognize the USB controllers, and the ohci and ehci drivers claimed them. I expect those drivers work fine, but it looks like they aren't getting interrupts. I could easily believe we have a problem with routing interrupts through the CardBus bridge at 00:08.0. Can you boot with "irqpoll" and see if that makes a difference? Please attach the *complete* dmesg log, e.g., output of the "dmesg" command. Created attachment 121361 [details]
dmesg with irqpoll in /proc/cmdline; kernel 3.13.0-rc6-4-default
I fear that there is no difference with and without the irqpoll kernel parameter
To summarize: the system has a CardBus bridge at 00:08.0. If you boot with the CardBus slot empty, then insert a UBS3.0 ExpressCard via PCMCIA adapter, we detect the insertion and enumerate the new PCI devices (attachment 120551 [details]) at 02:00.0 and 02:00.1: 00:08.0 CardBus bridge: O2 Micro, Inc. OZ601/6912/711E0 CardBus/SmartCardBus Controller Bus: primary=00, secondary=02, subordinate=05, sec-latency=176 02:00.0 USB controller: NEC Corporation OHCI USB Controller 02:00.1 USB controller: NEC Corporation uPD72010x USB 2.0 Controller pcmcia_socket pcmcia_socket0: pccard: CardBus card inserted into slot 0 pci 0000:02:00.0: [1033:0035] type 00 class 0x0c0310 pci 0000:02:00.1: [1033:00e0] type 00 class 0x0c0320 ohci-pci 0000:02:00.0: new USB bus registered, assigned bus number 3 ehci-pci 0000:02:00.1: new USB bus registered, assigned bus number 4 If you plug a USB stick into the USB3.0 ExpressCard, it doesn't work, and the USB devices receive no interrupts (ohci_hcd:usb3 and ehci_hcd:usb4 are both on IRQ5, and no IRQ5 was received between attachment 120531 [details] and attachment 120541 [details]). Just to double-check, you did supply "irqpoll" to the bootloader (as opposed to "echo irqpoll > /proc/cmdline" or something? Could you attach a complete dmesg, not just the excerpts we have so far? The kernel prints the command-line arguments at boot-time, and that's the only way to know for sure that it's doing what we expect. I can think of two possibilities: 1) Interrupts aren't getting from the USB device through the CardBus bridge. With "irqpoll", we should call every ISR on every timer interrupt, so this should work around the problem (with poor performance). 2) MMIO accesses from the driver aren't getting through the CardBus bridge to the USB device. This seems unlikely because the driver init seems to work fine. But seeing the entire dmesg log would let us verify that the BARs are assigned from valid regions. Created attachment 141361 [details]
dmesg with irqpoll in /proc/cmdline; kernel 3.13.0-rc6-4-default insert-remove (new)
No advance on this bug? various Express Cards (USB3.0, eSATA, etc.) are affected (generic ExpressCard, ExpressCard over PCMCIA).- Bug 87531 may be different but I guess that some kind of low level feature does miss here and there. Looks like this bug is with "ExpressCard via cardbus/ExpressCard adapter", right? If so, please update title accordingly. Does ExpressCard work on native ExpressCard slot? The bug can be observed with both the native ExpressCard slot and the ExpressCard via cardbus/ExpressCard adapter. The only difference is that with the cardbus/ExpressCard adapter at least some logging messages at card insertion/removal end up in the logs while with the native ExpressCard slot it does not react at all on card insertion/removal and USB insertion/removal (native slot last tested today with kernel 3.2.0-4-amd64). Consequently I wanna suggest that we start with testing the PCMCIA adapter since the PCMCIA interface is already more progressed (though we have wondered that there is simply nothing in the logs on USB plug/unplug into/from the ExpressCard even with irqpoll or a debug kernel: see the attachements). If you should really need some test with the native slot let us do that now with the old 3.2.0-4 kernel or in one or two weeks when my only computer with native Express Card slot will be repaired (sorry for the inconvenience; its power supply for recharging the batteries needs to be fixed). I would like to make ExpressCard slot working at first. Hi Yinghai! Further testing has shown that the USB3.0 ExpressCard is in deed recognized via the native slot; however only on cold-boot: I have opened Bug 87781 for this purpose. Can you try latest kernel? like 3.17 or 3.18-rc2? Please post boot log with "debug ignore_loglevel initcall_debug" and output from lspci -tv lspci -vvxxx Created attachment 157071 [details]
lspci -tv (3.18-rc3)
Created attachment 157081 [details]
lspci -vvxxx (3.18-rc3)
Booting with 3.18-rc3 and 'debug ignore_loglevel initcall_debug' there is simply nothing in the logs when I plug or unplug the adapter+ExpressCard+USBstick.
Created attachment 157091 [details]
dmesg (3.18-rc3 + part of 3.12.21 dmesg: Mageia)
Hmm, Mageia seems to strip the beginning of the dmesg (no early logging). Here is a concatenated dmesg.old + dmesg with 3.18-rc3 + a previous kernel. Hope that will help.
Bug 88801 may be related (about SCM PCMCIA CF adapter). It seems to be the same with Linux 4.0.1-1: events on plugging the USB3.0 adapter itself but no more events in dmesg when plugging new USB devices into the adapter. Created attachment 199061 [details]
dmesg.tail - of inserting merely the expresscard adapter without usb card
Could it be that the ExpressCard adapter is mis-recognized as USB adapter here? I have now retried to insert the adpater with 4.1.13-desktop-2.mga5 without any USB ExpressCard inside the adpater and it was apparently recognized as usb hub instead of an ExpressCard adapter. If this is the wrong driver which one would be the right one?
# lspcmcia
Socket 0 Bridge: [yenta_cardbus] (bus ID: 0000:00:08.0)
CardBus card -- see "lspci" for more information
# lspci | grep -i cardbus
00:08.0 CardBus bridge: O2 Micro, Inc. OZ601/6912/711E0 CardBus/SmartCardBus Controller
# dmesg | tail -n 2
[ 5007.133207] hub 3-0:1.0: USB hub found
[ 5007.133230] hub 3-0:1.0: 3 ports detected
confirmed for kernel 4.5.0-rc4 on an Athlon XP 3000 system. Note that the USB hub appears on insertion of the adapter not on insertion of the USB ExpressCard into the adapter. Could it be that the adapter is wrongly recognized as USB hub and can thus not serve its purpose? (i.e. there are no more plug events for the ExpressCard itself and the USB3 devices themselves, just for the adapter). Journal-Log follows in the next comment. Created attachment 206461 [details]
journalctl -xb: EcoAthlon
somehow similar: Bug 113441 - kernel does not receive any USB3.0 plug/unplug events in certain system configurations Created attachment 229541 [details]
dmesg with 4.8.0-rc1-ARCH-26316-g65ea11e
This one does not seem to have improved much with 4.8.0-rc1-ARCH-26316-g65ea11e. Nonetheless if anyone would be ready to do something about it just tell me what you would neeed ¿irqpoll-dmesg or the like?.
switched from 3.18 -> 4.8.0-rc1-ARCH-26316-g65ea11e |