|Summary:||Cardbus slots in Thinkpad Dock/Dock II fail IRQ allocation - T30|
|Product:||ACPI||Reporter:||Paul Martin (pm)|
|Severity:||normal||CC:||acpi-bugzilla, akpm, alan, goldenfish, lenb, rui.zhang, shaohua.li|
lspci -xvvv output
dmesg output, booting whilst docked
lspci -xvvv output, booting whilst docked
dmesg output segment, booted docked, undocking and redocking
lspci -xvvv output, booted docked, after undocking
lspci -xvvv output, booted docked, after undocking and redocking
try the debug patch
dmesg, using patch
try the debug patch
dmesg output, booting whilst docked with acpiphp_glue patch
try the debug patch to see whether the problem still exists
dmesg output, using Shaohua's patches
ti docking bridge patch
Description Paul Martin 2008-05-27 06:14:14 UTC
Comment 1 ykzhao 2008-05-27 19:17:02 UTC
Will you please attach the output of dmesg, acpidump and lspci -vxxx ? Thanks.
Comment 2 Shaohua 2008-05-27 19:21:52 UTC
Also can you plug the dock station before boot, and try if cardbus works. That is not try hotplug.
Comment 3 Paul Martin 2008-05-28 04:08:08 UTC
Here's the dmesg, acpidump and lspci -vxxx output. I should note that when the laptop is booted up when docked, DMA/IRQ routing is a little faulty in that the DVB-S card I have in my other dock (I have four: two Docks and two Dock IIs) consumes huge amounts of CPU whilst it's active. If it's docked after booting, the DMA/IRQ problem doesn't happen. After this, I'll be submitting a bug that the USB hub in the dock isn't recognised. But that's another story.
Comment 4 Paul Martin 2008-05-28 04:08:50 UTC
Created attachment 16303 [details] dmesg output
Comment 5 Paul Martin 2008-05-28 04:09:18 UTC
Created attachment 16304 [details] acpidump output
Comment 6 Paul Martin 2008-05-28 04:09:41 UTC
Created attachment 16305 [details] lspci -xvvv output
Comment 7 Paul Martin 2008-05-28 04:42:57 UTC
Created attachment 16306 [details] dmesg output, booting whilst docked This shows booting whilst docked, then inserting a Cardbus USB adaptor, ejecting it, then undocking and re-docking.
Comment 8 Paul Martin 2008-05-28 04:43:49 UTC
Created attachment 16307 [details] lspci -xvvv output, booting whilst docked This shows lspci output from just after booting whilst the laptop is docked.
Comment 9 Andrew Morton 2008-05-28 17:09:33 UTC
I tagged this as a regression, assuming you're certain about that "Early 2.6".
Comment 10 Shaohua 2008-05-28 19:08:26 UTC
hotplug dock: pci 0000:08:02.1: enabling device (0000 -> 0003) ACPI: Unable to derive IRQ for device 0000:08:02.1 ACPI: PCI Interrupt 0000:08:02.1[B]: no GSI dock on boot: ACPI: PCI Interrupt 0000:09:02.1[A] -> Link [LNKC] -> GSI 11 (level, low) -> IRQ 11 so the real reason is the pin register read as B in hotplug, but it should be A really.
Comment 11 Shaohua 2008-05-28 20:06:47 UTC
this is strange, pin register usually is readonly. Paul, can try set the pin register (with setpci tool) of 08:02.1 in hotplug dock case and then read it again (with lspci). I'd like to check if the register can be write.
Comment 12 ykzhao 2008-05-28 23:49:57 UTC
Hi, Paul What Shaohua said in comment #10 and #11 is right. It is very strange that the interrupt pin from the PCI device is different in the two cases. (When the system is booted with dock, the interrupt pin is A. When the dock is hotplugged , the interrupt pin is B.) Will you please do the following test? a. boot the system with dock station. b. unplug the dock station and get the output of dmesg, lspci -vxxx c. hotplug the dock station again and get the output of dmesg, lspci -vxxx. Thanks.
Comment 13 Paul Martin 2008-05-29 05:20:23 UTC
Created attachment 16313 [details] dmesg output segment, booted docked, undocking and redocking This is the continuation of attachment "16306: dmesg output, booting whilst docked" showing undocking and re-docking.
Comment 14 Paul Martin 2008-05-29 05:23:05 UTC
Created attachment 16314 [details] lspci -xvvv output, booted docked, after undocking
Comment 15 Paul Martin 2008-05-29 05:23:34 UTC
Created attachment 16315 [details] lspci -xvvv output, booted docked, after undocking and redocking
Comment 16 Paul Martin 2008-05-29 05:32:20 UTC
Tried the following command, without getting any visible change in lspci output. setpci -v -G -s 18:02.1 INTERRUPT_PIN=0
Comment 17 ykzhao 2008-05-30 00:32:30 UTC
Created attachment 16333 [details] try the debug patch Will you please try the debug patch and do the test as described in comment #12? Thanks.
Comment 18 Paul Martin 2008-05-30 04:45:11 UTC
Created attachment 16335 [details] dmesg, using patch $ strings /lib/modules/2.6.26-rc4/kernel/drivers/acpi/dock.ko|grep Fail <3>ACPI: Failure in _INI Object $ dmesg|grep Failure $ There is no change whatsoever to the lspci -xvvv outputs, so I've not uploaded them. It's still Interrupt: pin B routed to IRQ 255 on re-docking.
Comment 19 ykzhao 2008-06-01 23:55:59 UTC
Created attachment 16363 [details] try the debug patch Will you please try the debug patch and do the test described in comment #12 again? Will you please confirm whether windows can work well when the dock station is hotplugged? (Had better check whether correct IRQ number is allocated to all the carbus controller). Thanks.
Comment 20 Paul Martin 2008-06-02 03:48:32 UTC
What's windows? I don't have a copy to test it with. I've not used it for over ten years. This laptop was bought second hand, with the o/s wiped. I'll try the acpiphp_glue patch today.
Comment 21 Len Brown 2008-06-02 18:44:27 UTC
Does this work with acpi=off? (presumably via some SMM BIOS magic) What is the latest release of Linux that works properly? Was ACPI enabled in that release?
Comment 22 Paul Martin 2008-06-03 07:16:49 UTC
Tried the patch. Major regression with it. The dock bridge is no longer detected if booted up whilst docked, and it's no longer possible to undock. If booted up undocked, then docked, lspci reports garbage for the bridge and everything behind it. Attaching dmesg output. Will revert the patch to confirm that it is what is causing the regression (ie. not hardware fault). Len Brown: I'm afraid that I forget which kernel worked last. I'll have to experiment on a spare partition if you want me to bisect back into 2.4 territory. I've always had to use ACPI with this laptop, as APM doesn't allow hotplugging the Ultrabay.
Comment 23 Paul Martin 2008-06-03 07:17:43 UTC
Created attachment 16376 [details] dmesg output, booting whilst docked with acpiphp_glue patch
Comment 24 Paul Martin 2008-06-03 08:02:25 UTC
Comment on attachment 16376 [details] dmesg output, booting whilst docked with acpiphp_glue patch Possibly improperly docked. After power cycling, there was no difference from earlier patches.
Comment 25 Paul Martin 2008-06-03 09:00:54 UTC
Confirmed. Recompiled with and without the acpiphp_glue.c patch, with no difference in the dmesg or lspci -xvvvv outputs either way.
Comment 26 Len Brown 2008-06-13 18:44:19 UTC
clearing the regression flag, since we don't have any information about any previous release that worked.
Comment 27 ykzhao 2008-07-20 19:56:39 UTC
Created attachment 16915 [details] try the debug patch to see whether the problem still exists Will you please try the debug patch and do the test described in comment #12 again? Thanks.
Comment 28 Paul Martin 2008-07-21 06:31:54 UTC
(In reply to comment #27) > Created an attachment (id=16915) [details] > try the debug patch to see whether the problem still exists Initial results (booting whilst undocked and then docking) show no difference. I'm using a stock 2.6.26 kernel on a T42 with a Dock II. (My T30 died with the DIMM socket solder cracking problem.) There's another, possibly related, problem which I hinted at before. The integrated USB hub in the dock does not get recognised on docking after boot, but is recognised when booted up whilst docked. Conversely, there's a DMA problem with PCI cards in the dock if you boot up whilst docked, but not if you dock after boot. I also do now have a WinXP installation I can test.
Comment 29 ykzhao 2008-09-17 19:44:15 UTC
Hi, Paul Shaohua sent a patch set about the dock/hotplug. Will you please try the patch set? http://marc.info/?l=linux-acpi&m=121980628528699&w=2 Thanks.
Comment 30 Paul Martin 2008-10-16 14:27:33 UTC
Created attachment 18342 [details] dmesg output, using Shaohua's patches Have tried the patches from Shaohua. They fix the detection of the USB hub built into the dock, but that's not this bug. On booting undocked, then docking, the docking event isn't detected. It appears to be that it assumes it's already docked. On pressing the undock button, an undock event happens, then you can re-dock with the event being detected correctly. Similarly, the Ultrabay (built-in, not in dock) only seems to be generating an ACPI eject event every second time the bay eject is requested. It doesn't fix the Yenta problem, I'm afraid. The attached dmesg output is from being booted up docked, inserting a PCMCIA card, ejecting it, undocking, then re-docking. Hardware: Thinkpad T42, Dock II.
Comment 31 ykzhao 2008-11-16 23:52:07 UTC
Hi, Paul Thanks for the test. It seems that the issue raised by Shaohua in comment #10 can't fixed by the patch set: http://marc.info/?l=linux-acpi&m=121980628528699&w=2 It is very strange that the interrupt pin from the PCI device is different in the two cases. (When the system is booted with dock, the interrupt pin is A. When the dock is hotplugged , the interrupt pin is B.) Sorry that I have no idea why this happens.
Comment 32 Paul Martin 2008-11-17 02:25:10 UTC
One thought is that there is some initialisation of the hardware that is not happening on hotplugging. With your patches, the dock isn't recognised until the *second* time it's hotplugged.
Comment 33 Pavel Kysilka 2008-11-17 06:49:04 UTC
Created attachment 18888 [details] ti docking bridge patch This modified patch may be helpfull with error with docking bridge irq allocation. More described there: http://bugzilla.kernel.org/show_bug.cgi?id=7264 Original patch was created by Kristen Carlson Accardi .
Comment 34 Paul Martin 2008-11-18 04:58:44 UTC
I can confirm that this patch works with a Thinkpad T42 and the Dock II on 2.6.28-rc5, and that both Cardbus slots work. Now to find which one of Shaohua's patches fixed the USB problem (which still exists in 2.6.28-rc5).
Comment 35 Zhang Rui 2008-11-18 17:51:51 UTC
mark this as a duplicate of bug #7264 *** This bug has been marked as a duplicate of bug 7264 ***
Comment 36 Paul Martin 2009-01-05 12:31:23 UTC
Any chance of someone pushing this patch up the chain to Linus? http://bugzilla.kernel.org/attachment.cgi?id=18888
Comment 37 ykzhao 2009-01-05 17:09:51 UTC
Hi, Pavel How about pushing the patch to upstream kernel? http://bugzilla.kernel.org/show_bug.cgi?id=7264#C25? Thanks.
Comment 38 ykzhao 2009-02-01 21:10:01 UTC
*** This bug has been marked as a duplicate of bug 7264 ***
Comment 39 Paul Martin 2009-02-02 03:12:19 UTC
Any chance it might get pushed upstream? Also bug 7264 shouldn't be marked as REJECTED INVALID, as it's a real bug.
Comment 40 ykzhao 2009-02-02 17:02:31 UTC
Understand what you said. But this bug is related with the hardware issue. IMO it is difficult to push it into upstream kernel. thanks.
Comment 41 Len Brown 2009-02-21 08:50:45 UTC
If we know what the proper quirks are to fix some machines and not break other machines, we generally ship them. However, the quirk in comment #33 appears to be exactly the patch that was reverted in bug 7264. Did we fail to close the loop on this and produce a quirk that helps some thinkpads without breaking others? What is the current state of the upstream kernel on the hardware in question?
Comment 42 Paul Martin 2009-02-21 09:33:45 UTC
Pavel's quirk patch works on T22, T23, T30, T42. The reverted patch (commit c408a3794d6222ab43ab26648385f850a82f0803) has: + val = ((val & 0x00ffff00) | 0x2864c077); Pavel's patch has: + val = ((val & 0x00ffff00) | (0x2864c077 | 0xa864c077)); but (0x2864c077 | 0xa864c077) == 0xa864c077
Comment 43 Shaohua 2009-07-01 03:06:38 UTC
Since the new patch has a little difference than the revertted patch, can we push the new patch to -mm tree for wide test?
Comment 44 Zhang Rui 2009-08-12 06:26:35 UTC
Shaohua, what's the status of this bug? can you help push the proper patch upstream?
Comment 45 Zhang Rui 2009-10-09 02:39:27 UTC
Comment 46 Alan 2010-01-19 17:44:23 UTC
Ping ? shall I close this bug as dead ?
Comment 47 Paul Martin 2010-01-19 19:21:43 UTC
Please don't close the bug. The patch is still necessary, only no-one seems to have sent it to Linus yet. I still need the patch for the dock's cardbus slots to work with my T41.
Comment 48 Alan 2010-01-19 19:23:31 UTC
Given the time scales I'd just send it to Linus and point him at the bug report.
Comment 49 Shaohua 2010-02-22 02:20:11 UTC
can you please try boot option acpi_os_name="Microsoft Windows" without any patch applied? It appears the registers set by the quirk can be set by bios automatically if the os is windows 98.
Comment 50 Paul Martin 2010-02-22 10:40:17 UTC
Recompiled with a virgin git export, booted with acpi_os_name="Microsoft Windows". It didn't work. I'm using a T42 nowadays. dmesg extract: Linux version 2.6.33-rc8-00164-gaea187c (root@thinkpad) (gcc version 4.4.3 (Debi an 4.4.3-2) ) #71 PREEMPT Mon Feb 22 09:20:04 GMT 2010 ... Kernel command line: BOOT_IMAGE=/vmlinuz-2.6.33-rc8-00164-gaea187c root=UUID=ee167295-0701-4887-8d48-604912b45b88 ro blacklist=piix log_buf_len=128k hpet=force acpi_os_name=Microsoft Windows ... thinkpad_acpi: ThinkPad BIOS 1RETDRWW (3.23 ), EC 1RHT71WW-3.04 thinkpad_acpi: IBM ThinkPad T42, model 2374BW7 ... yenta_cardbus 0000:08:02.1: CardBus bridge found [1014:0148] yenta_cardbus 0000:08:02.1: Using CSCINT to route CSC interrupts to PCI yenta_cardbus 0000:08:02.1: Routing CardBus interrupts to PCI yenta_cardbus 0000:08:02.1: TI: mfunc 0x00001000, devctl 0x66 yenta_cardbus 0000:08:02.1: request_irq() in yenta_probe_cb_irq() failed! yenta_cardbus 0000:08:02.1: TI: no PCI interrupts. Fish. Please report. yenta_cardbus 0000:08:02.1: no PCI IRQ, CardBus support disabled for this socket. yenta_cardbus 0000:08:02.1: check your BIOS CardBus, BIOS IRQ or ACPI settings. yenta_cardbus 0000:08:02.1: ISA IRQ mask 0x0000, PCI irq 0 yenta_cardbus 0000:08:02.1: Socket status: 30000006 yenta_cardbus 0000:08:02.1: pcmcia: parent PCI bridge I/O window: 0x5000 - 0x6fff pcmcia_socket pcmcia_socket3: cs: IO port probe 0x5000-0x6fff: clean. yenta_cardbus 0000:08:02.1: pcmcia: parent PCI bridge Memory window: 0x8c000000 - 0x95ffffff yenta_cardbus 0000:08:02.1: pcmcia: parent PCI bridge Memory window: 0x84000000 - 0x8bffffff yenta_cardbus 0000:08:02.1: pcmcia: parent PCI bridge I/O window: 0x4000 - 0x8fff yenta_cardbus 0000:08:02.1: pcmcia: parent PCI bridge Memory window: 0xc0200000 - 0xcfffffff yenta_cardbus 0000:08:02.1: pcmcia: parent PCI bridge Memory window: 0xe8000000 - 0xefffffff pcmcia_socket pcmcia_socket3: cs: IO port probe 0x100-0x4ff: excluding 0x4d0-0x4d7 pcmcia_socket pcmcia_socket3: cs: IO port probe 0x800-0x8ff: clean. pcmcia_socket pcmcia_socket3: cs: IO port probe 0xc00-0xcff: clean. pcmcia_socket pcmcia_socket3: cs: IO port probe 0xa00-0xaff: clean.
Comment 51 Paul Martin 2010-02-22 11:03:26 UTC
Grub was eating the quotes. Even with that fixed, the Cardbus slots don't get IRQ allocation. There are the same errors as in the previous comment. One quirk of using acpi_os_name="Microsoft Windows" is that the first attempt to dock with the docking station doesn't get detected by the kernel. Undocking and immediately redocking does work. This happens even when Pavel's patch is included (and the Cardbus slots get correct IRQs with Pavel's patch). Incidentally, adding acpi_os_name="Microsoft Windows" fixes a problem where the USB hub in the docking station wasn't recognised if the laptop had been booted undocked.
Comment 52 Shaohua 2010-02-23 01:29:02 UTC
Created attachment 25169 [details] debug patch then can you try attached patch please? it executes _REG method and should do the config space change.
Comment 53 Paul Martin 2010-02-23 03:13:18 UTC
Having removed Pavel's patch, I tried it with and without acpi_os_name="Microsoft Windows". dmesg: yenta_cardbus 0000:08:02.1: CardBus bridge found [1014:0148] yenta_cardbus 0000:08:02.1: Using CSCINT to route CSC interrupts to PCI yenta_cardbus 0000:08:02.1: Routing CardBus interrupts to PCI yenta_cardbus 0000:08:02.1: TI: mfunc 0x00001000, devctl 0x66 yenta_cardbus 0000:08:02.1: request_irq() in yenta_probe_cb_irq() failed! yenta_cardbus 0000:08:02.1: TI: no PCI interrupts. Fish. Please report. yenta_cardbus 0000:08:02.1: no PCI IRQ, CardBus support disabled for this socket. yenta_cardbus 0000:08:02.1: check your BIOS CardBus, BIOS IRQ or ACPI settings. yenta_cardbus 0000:08:02.1: ISA IRQ mask 0x0000, PCI irq 0 yenta_cardbus 0000:08:02.1: Socket status: 30000006
Comment 54 Shaohua 2010-02-24 08:38:43 UTC
Created attachment 25181 [details] debug patch Looks the _REG method is executed too early. can you please try the updated patch.
Comment 55 Paul Martin 2010-02-24 12:20:15 UTC
The patch from comment #54 works, but only if acpi_os_name isn't forced. (The dock's USB hub still isn't seen without the acpi_os_name forcing, but that probably ought to be its own bug.)
Comment 56 Shaohua 2010-02-25 00:57:39 UTC
Great the debug patch works, I'll send a patch out. I have no idea about the USB hub issue, better a USB guy can look at it.
Comment 57 Shaohua 2010-02-25 03:05:19 UTC
A patch is sent out to lenb. Mark this one as resolved. for the usb issue, please open a new track.
Comment 58 Len Brown 2010-03-31 23:29:21 UTC
commit d06070509147c948a06056da619c9dc2ed349805 Author: Shaohua Li <email@example.com> Date: Thu Feb 25 10:59:34 2010 +0800 acpiphp: Execute ACPI _REG method for hotadded devices shipped in linux 2.6.34-rc2 closed.