Bug 10805

Summary: Cardbus slots in Thinkpad Dock/Dock II fail IRQ allocation - T30
Product: ACPI Reporter: Paul Martin (pm)
Component: Config-HotplugAssignee: Shaohua (shaohua.li)
Status: CLOSED CODE_FIX    
Severity: normal CC: acpi-bugzilla, akpm, alan, goldenfish, lenb, rui.zhang, shaohua.li
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 2.6.26-rc4 Tree: Mainline
Regression: No
Attachments: dmesg output
acpidump output
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
debug patch
debug patch

Description Paul Martin 2008-05-27 06:14:14 UTC
Latest working kernel version: Early 2.6 -- not worked for a good while
Distribution: Debian
Hardware Environment: Thinkpad T30 + Dock or Dock II
Problem Description:

The Cardbus slots are recognised, but due to one of them not getting allocated an IRQ, the initialization of both fails.

ACPI: \_SB_.PCI0.PCI1.DOCK - docking
acpiphp_glue: handle_hotplug_event_func: Bus check notify on \_SB_.PCI0.PCI1.DOCK
PCI: Found 0000:02:03.0 [104c/ac22] 000604 01
PCI: Scanning behind PCI bridge 0000:02:03.0, config 000000, pass 0
PCI: Scanning behind PCI bridge 0000:02:03.0, config 000000, pass 1
PCI: Scanning bus 0000:08
PCI: Found 0000:08:01.0 [1095/0648] 000101 00
PCI: Found 0000:08:02.0 [104c/ac51] 000607 02
PCI: Found 0000:08:02.1 [104c/ac51] 000607 02
PCI: Fixups for bus 0000:08
PCI: Transparent bridge - 0000:02:03.0
PCI: Scanning behind PCI bridge 0000:08:02.0, config 000000, pass 0
PCI: Scanning behind PCI bridge 0000:08:02.1, config 000000, pass 0
PCI: Scanning behind PCI bridge 0000:08:02.0, config 000000, pass 1
PCI: Bus #09 (-#0c) is partially hidden behind transparent bridge #02 (-#08)
PCI: Scanning behind PCI bridge 0000:08:02.1, config 000000, pass 1
PCI: Bus #0d (-#10) is partially hidden behind transparent bridge #02 (-#08)
PCI: Bus scan for 0000:08 returning with max=10
PCI: Bus #08 (-#10) is partially hidden behind transparent bridge #02 (-#08)
PCI: region 0000:08:02.0/9 too large: 0x0000000000000000-0x0000000003ffffff
PCI: region 0000:08:02.1/9 too large: 0x0000000000000000-0x0000000003ffffff
PCI: region 0000:08:02.0/10 too large: 0x0000000000000000-0x0000000003ffffff
PCI: region 0000:08:02.1/10 too large: 0x0000000000000000-0x0000000003ffffff
acpiphp_glue: bus exists... trim
acpiphp_glue: acpi_bus_trim return 0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCI1.DOCK._PRT]
PCI: Bus 3, cardbus bridge: 0000:02:00.0
  IO window: 0x00004000-0x000040ff
  IO window: 0x00004400-0x000044ff
  PREFETCH window: 0xf0000000-0xf3ffffff
  MEM window: 0xd4000000-0xd7ffffff
PCI: Bus 7, cardbus bridge: 0000:02:00.1
  IO window: 0x00004800-0x000048ff
  IO window: 0x00004c00-0x00004cff
  PREFETCH window: 0xf4000000-0xf7ffffff
  MEM window: 0xd8000000-0xdbffffff
  got res [d0300000:d0300fff] bus [d0300000:d0300fff] flags 20200 for BAR 0 of 0000:08:02.0
PCI: moved device 0000:08:02.0 resource 0 (20200) to d0300000
  got res [d0301000:d0301fff] bus [d0301000:d0301fff] flags 20200 for BAR 0 of 0000:08:02.1
PCI: moved device 0000:08:02.1 resource 0 (20200) to d0301000
  got res [6000:600f] bus [6000:600f] flags 20101 for BAR 4 of 0000:08:01.0
  got res [6000:600f] bus [6000:600f] flags 20101 for BAR 4 of 0000:08:01.0
PCI: moved device 0000:08:01.0 resource 4 (20101) to 6000
  got res [6010:6017] bus [6010:6017] flags 20101 for BAR 0 of 0000:08:01.0
PCI: moved device 0000:08:01.0 resource 0 (20101) to 6010
  got res [6018:601f] bus [6018:601f] flags 20101 for BAR 2 of 0000:08:01.0
PCI: moved device 0000:08:01.0 resource 2 (20101) to 6010
  got res [6020:6023] bus [6020:6023] flags 20101 for BAR 1 of 0000:08:01.0
PCI: moved device 0000:08:01.0 resource 1 (20101) to 6020
  got res [6024:6027] bus [6024:6027] flags 20101 for BAR 3 of 0000:08:01.0
PCI: moved device 0000:08:01.0 resource 3 (20101) to 6020
PCI: Bus 9, cardbus bridge: 0000:08:02.0
  IO window: 0x00005000-0x000050ff
  IO window: 0x00005400-0x000054ff
PCI: Bus 13, cardbus bridge: 0000:08:02.1
  IO window: 0x00005800-0x000058ff
  IO window: 0x00005c00-0x00005cff
PCI: Bridge: 0000:02:03.0
  IO window: 5000-6fff
  MEM window: 0xd0300000-0xd03fffff
  PREFETCH window: disabled.
decode_hpp: Could not get hotplug parameters. Use defaults
pci 0000:02:03.0: enabling device (0000 -> 0003)
PCI: Enabling bus mastering for device 0000:02:03.0
pci 0000:08:02.0: enabling device (0000 -> 0003)
ACPI: PCI Interrupt 0000:08:02.0[A] -> Link [LNKC] -> GSI 11 (level, low) -> IRQ 11
PCI: Enabling bus mastering for device 0000:08:02.0
PCI: Setting latency timer of device 0000:08:02.0 to 64
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
PCI: Enabling bus mastering for device 0000:08:02.1
PCI: Setting latency timer of device 0000:08:02.1 to 64
Yenta: CardBus bridge found at 0000:08:02.0 [1014:0148]
PCI: Bus 9, cardbus bridge: 0000:08:02.0
  IO window: 0x00005000-0x000050ff
  IO window: 0x00005400-0x000054ff
  PREFETCH window: 0xd0400000-0xd07fffff
  MEM window: 0xd0800000-0xd0bfffff
Yenta: Enabling burst memory read transactions
Yenta: Using CSCINT to route CSC interrupts to PCI
Yenta: Routing CardBus interrupts to PCI
Yenta TI: socket 0000:08:02.0, mfunc 0x00001000, devctl 0x66
Yenta: ISA IRQ mask 0x0000, PCI irq 11
Socket status: 30000006
pcmcia: parent PCI bridge I/O window: 0x5000 - 0x6fff
cs: IO port probe 0x5000-0x6fff: clean.
pcmcia: parent PCI bridge Memory window: 0xd0300000 - 0xd03fffff
pcmcia: parent PCI bridge I/O window: 0x4000 - 0x8fff
pcmcia: parent PCI bridge Memory window: 0xd0200000 - 0xdfffffff
pcmcia: parent PCI bridge Memory window: 0xf0000000 - 0xf7ffffff
Yenta: CardBus bridge found at 0000:08:02.1 [1014:0148]
PCI: Bus 13, cardbus bridge: 0000:08:02.1
  IO window: 0x00005800-0x000058ff
  IO window: 0x00005c00-0x00005cff
  PREFETCH window: 0xd0c00000-0xd0ffffff
  MEM window: 0xd1000000-0xd13fffff
Yenta: Using CSCINT to route CSC interrupts to PCI
Yenta: Routing CardBus interrupts to PCI
Yenta TI: socket 0000:08:02.1, mfunc 0x00001000, devctl 0x66
Yenta: request_irq() in yenta_probe_cb_irq() failed!
Yenta TI: socket 0000:08:02.1 no PCI interrupts. Fish. Please report.
Yenta: no PCI IRQ, CardBus support disabled for this socket.
Yenta: check your BIOS CardBus, BIOS IRQ or ACPI settings.
Yenta: ISA IRQ mask 0x0000, PCI irq 0
Socket status: 30000006
pcmcia: parent PCI bridge I/O window: 0x5000 - 0x6fff
cs: IO port probe 0x5000-0x6fff: clean.
pcmcia: parent PCI bridge Memory window: 0xd0300000 - 0xd03fffff
pcmcia: parent PCI bridge I/O window: 0x4000 - 0x8fff
pcmcia: parent PCI bridge Memory window: 0xd0200000 - 0xdfffffff
pcmcia: parent PCI bridge Memory window: 0xf0000000 - 0xf7ffffff
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
ping shaohua...
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 <shaohua.li@intel.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.