Will you please attach the output of dmesg, acpidump and lspci -vxxx ? 
Thanks.

Also can you plug the dock station before boot, and try if cardbus works. That is not try hotplug.

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.

Created attachment 16303 [details]
dmesg output

Created attachment 16304 [details]
acpidump output

Created attachment 16305 [details]
lspci -xvvv output

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.

Created attachment 16307 [details]
lspci -xvvv output, booting whilst docked

This shows lspci output from just after booting whilst the laptop is docked.

I tagged this as a regression, assuming you're certain about
that "Early 2.6".

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.

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.

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.

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.

Created attachment 16314 [details]
lspci -xvvv output, booted docked, after undocking

Created attachment 16315 [details]
lspci -xvvv output, booted docked, after undocking and redocking

Tried the following command, without getting any visible change in lspci output.

    setpci -v -G -s 18:02.1 INTERRUPT_PIN=0

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.

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.

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.

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.

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?

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.

Created attachment 16376 [details]
dmesg output, booting whilst docked with acpiphp_glue patch

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.

Confirmed. Recompiled with and without the acpiphp_glue.c patch, with no difference in the dmesg or lspci -xvvvv outputs either way.

clearing the regression flag, since we don't have any information
about any previous release that worked.

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.

(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.

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.

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.

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.
    

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.

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 .

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).

mark this as a duplicate of bug #7264

*** This bug has been marked as a duplicate of bug 7264 ***

Any chance of someone pushing this patch up the chain to Linus?

http://bugzilla.kernel.org/attachment.cgi?id=18888

Hi, Pavel
    How about pushing the patch to upstream kernel?
    http://bugzilla.kernel.org/show_bug.cgi?id=7264#C25?
    Thanks.
    

*** This bug has been marked as a duplicate of bug 7264 ***

Any chance it might get pushed upstream? Also bug 7264 shouldn't be marked as REJECTED INVALID, as it's a real bug.

Understand what you said. But this bug is related with the hardware issue. 
    IMO it is difficult to push it into upstream kernel. 
    thanks.
    

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?

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

Since the new patch has a little difference than the revertted patch, can we push the new patch to -mm tree for wide test?

Shaohua,
what's the status of this bug?
can you help push the proper patch upstream?

ping shaohua...

Ping ? shall I close this bug as dead ?

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.

Given the time scales I'd just send it to Linus and point him at the bug report.

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.

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.

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.

Created attachment 25169 [details]
debug patch

then can you try attached patch please? it executes _REG method and should do the config space change.

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

Created attachment 25181 [details]
debug patch

Looks the _REG method is executed too early. can you please try the updated patch.

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.)

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.

A patch is sent out to lenb. Mark this one as resolved. for the usb issue, please open a new track.

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.