Bug 7304

Summary: [PATCH]no PCI irq, Cardbus support disabled
Product: Drivers Reporter: Thomas Nemeth (nemeth.thomas)
Component: PCMCIAAssignee: linux-pcmcia
Status: NEW ---    
Severity: normal CC: alan, alex.harford, bjorn.helgaas, jrnieder, komurojun-mbn, linux, manfred, protasnb, rmk
Priority: P2    
Hardware: i386   
OS: Linux   
Kernel Version: 3.2 Subsystem:
Regression: Yes Bisected commit-id:
Attachments: Boot message for a 2.6.17 kernel
List of interruptions from /proc
iomem from /proc
ioports from /proc
output of lspci
Boot message for a 2.4.27 kernel for comparison
Interrupts for 2.4
iomem from /proc for 2.4
ioports from /proc for 2.4
output of lspci for 2.4
Boot message for a 2.6.18 kernel
CPU info for 2.6.18
kernel build information for 2.6.18
Software environment (output of ver_linux) for 2.6.18
Software environment (output of ver_linux) for 2.4.27
Boot messages with kernel command line option acpi=force (2.6.18)
Toshiba Cardbus bridge not working Gentoo 2.6.19.r5 & Ubuntu 2.6.17
Boot messages for a 2.6.21 kernel
Dmesg of 2.6.25.6 with yenta_socket module insertion.
Boot messages of 2.2.27-pre2
Modules list for 2.2.27-pre2
List of interruptions for 2.2.27-pre2
List of PCI devices for 2.2.27-pre2
IO ports for 2.2.27-pre2
Boot messages of 2.4.22
List of modules for 2.4.22
PCI listing for 2.4.22
IO mem for 2.4.22
IO ports for 2.4.22
Patch to force CardBus support in yenta socket even when no IRQ is found.
Boot messages of 2.6.26.2 with yenta patch applied
Strace dump when calling ifconfig when yenta patch is applied
Boot messages of 2.6.26.2 with yenta patch applied
Boot messages for 2.6.25.6 with IRQ forced to 11.
Boot messages for 2.6.33 with IRQ forced to 11.
Boot messages for 2.6.33 with IRQ forced to 3...
Boot messages for 2.6.33 with the 3 pcmcia specified patches in comment #51
cbdump for 2.6.26.2
cbdump for 2.6.33
output of lspci -vvxxx on 2.6.33
output of lspci -H 2 -vvxxx on 2.2.27
dmidecode output on 2.6.33 with IRQ 11 forced.
Boot messages for 2.6.34-rc2 with IRQ forced to 11.
Output of cbdump on 2.6.34-rc2 with the eth card in the non-working slot
Output of cbdump on 2.6.34-rc2 with the eth card in the working slot
test patch to use ISA IRQs also for CardBus
Boot messages for 2.6.34-rc2 with applied patch
Patch to force IRQ number as a module parameter.

Description Thomas Nemeth 2006-10-11 02:15:33 UTC
Most recent kernel where this bug did not occur: 2.6.18
Distribution: Debian testing
Hardware Environment: Toshiba laptop (300CDT)
Software Environment: Fully functionnal distro
Problem Description:
  Since passing from 2.4 to 2.6, I could no more use my pcmcia ethernet card
  with a 2.6.x kernel (2.4 works nice in this regard). The boot message is
  always the same:
 PCI: No IRQ known for interrupt pin A of device 0000:00:13.0
 Yenta: CardBus bridge found at 0000:00:13.0 [1179:0001]
 Yenta: no PCI IRQ, CardBus support disabled for this socket.
 Yenta: check your BIOS CardBus, BIOS IRQ or ACPI settings.
 irq11: nobody cared (try booting with the "irqpoll" option)
 ... (see log files)

  Needless to say that I tried every kernel parameter found in Documentation/
  related to ACPI, PCI and APM, and I double-checked every possible option in
  my very limited old BIOS.

Steps to reproduce:
  001. take a toshiba satellite 300CDT
  010. use a 2.6.x enabled distro
  011. boot
  100. watch boot message
  101. try to use a network pcmcia card.
Comment 1 Thomas Nemeth 2006-10-11 02:18:55 UTC
Created attachment 9205 [details]
Boot message for a 2.6.17 kernel

This shows the typical boot messages I get with a 2.6.x kernel
Comment 2 Thomas Nemeth 2006-10-11 02:20:08 UTC
Created attachment 9206 [details]
List of interruptions from /proc
Comment 3 Thomas Nemeth 2006-10-11 02:20:45 UTC
Created attachment 9207 [details]
iomem from /proc
Comment 4 Thomas Nemeth 2006-10-11 02:22:08 UTC
Created attachment 9208 [details]
ioports from /proc
Comment 5 Thomas Nemeth 2006-10-11 02:23:28 UTC
Created attachment 9209 [details]
output of lspci
Comment 6 Thomas Nemeth 2006-10-11 02:24:41 UTC
Created attachment 9210 [details]
Boot message for a 2.4.27 kernel for comparison
Comment 7 Thomas Nemeth 2006-10-11 02:25:36 UTC
Created attachment 9211 [details]
Interrupts for 2.4
Comment 8 Thomas Nemeth 2006-10-11 02:26:31 UTC
Created attachment 9212 [details]
iomem from /proc for 2.4
Comment 9 Thomas Nemeth 2006-10-11 02:27:08 UTC
Created attachment 9213 [details]
ioports from /proc for 2.4
Comment 10 Thomas Nemeth 2006-10-11 02:27:54 UTC
Created attachment 9214 [details]
output of lspci for 2.4
Comment 11 Thomas Nemeth 2006-10-11 04:01:18 UTC
Created attachment 9215 [details]
Boot message for a 2.6.18 kernel
Comment 12 Thomas Nemeth 2006-10-11 04:03:16 UTC
Created attachment 9216 [details]
CPU info for 2.6.18
Comment 13 Thomas Nemeth 2006-10-11 04:05:29 UTC
Created attachment 9217 [details]
kernel build information for 2.6.18
Comment 14 Thomas Nemeth 2006-10-11 04:21:38 UTC
Created attachment 9218 [details]
Software environment (output of ver_linux) for 2.6.18
Comment 15 Thomas Nemeth 2006-10-11 04:22:05 UTC
Created attachment 9219 [details]
Software environment (output of ver_linux) for 2.4.27
Comment 16 Thomas Nemeth 2006-10-11 04:28:39 UTC
I made an error:
Most recent kernel where this bug did NOT occur: 2.4.27 (to my knowledge, didn't
test with 2.4.x > 2.4.27)
Comment 17 Komuro 2006-10-28 19:43:40 UTC
Please try to add "acpi=force" to the kernel-command-line.


Best Regards
Komuro


Comment 18 Thomas Nemeth 2006-10-29 03:56:36 UTC
Created attachment 9373 [details]
Boot messages with kernel command line option acpi=force (2.6.18)

These are the boot messages I get when using the acpi=force option. Until now
I thought that it was acpi the problem so I had to disable it. The results of
this option may show I was right :(
I inserted the cardbus after boot and the message about cardbus support is
still the same...
Comment 19 Thomas Nemeth 2006-10-29 04:05:50 UTC
Hi komuro!
Thank you for trying to help! Unfortunately I was not able to get good results
with acpi=force as you can see in the new attachment I made. As I said in my
previous comment, I though acpi was the problem.

May be is there a better combination of boot options I should use instead of
the ones I tried until now, but it's not something I can find out since the
error messages I get are not really usefull :(

I will provide anyone who asks to as many log he/she wants, try any option I
am asked to. The only thing I can't do is compiling a custom kernel since this
computer is quite old (pentium I MMX @ 166Mhz with 80Mb RAM) and it would take
hours/days to have a functionnal kernel...

Thanks to anyone that can help me fix this!

Thomas.
Comment 20 Turtle 2007-03-17 17:25:44 UTC
Created attachment 10810 [details]
Toshiba Cardbus bridge not working Gentoo 2.6.19.r5 & Ubuntu 2.6.17

I have a script posted on Gentoo's forums. It is helpful in diagnosing pcmcia
issues.
I get this output:
pcmcia-tool
list everything we know about this card
Socket 0:
  3.3V 32-bit PC Card
Socket 0 Bridge:	[yenta_cardbus] 	(bus ID: 0000:01:0b.0)
  CardBus card -- see "lspci" for more information
PRODID_1=""
PRODID_2=""
PRODID_3=""
PRODID_4=""
MANFID=0000,0000
FUNCID=255
Socket 0:
  no product info available
dmesg:
Kernel command line: root=/dev/hda3 pci=assign-busses pci=routeirq Panic=5
ACPI: bus type pci registered
pci_get_subsys() called while pci_devices is still empty
pci_get_subsys() called while pci_devices is still empty
pci_get_subsys() called while pci_devices is still empty
pci_get_subsys() called while pci_devices is still empty
pci_get_subsys() called while pci_devices is still empty
pci_get_subsys() called while pci_devices is still empty
pci_get_subsys() called while pci_devices is still empty
pci_get_subsys() called while pci_devices is still empty
pci_get_subsys() called while pci_devices is still empty
pci_get_subsys() called while pci_devices is still empty
pci_get_subsys() called while pci_devices is still empty
pci_get_subsys() called while pci_devices is still empty
pci_get_subsys() called while pci_devices is still empty
pci_get_subsys() called while pci_devices is still empty
pci_get_subsys() called while pci_devices is still empty
pci_get_subsys() called while pci_devices is still empty
pci_get_subsys() called while pci_devices is still empty
pci_get_subsys() called while pci_devices is still empty
pci_get_subsys() called while pci_devices is still empty
pci_get_subsys() called while pci_devices is still empty
pci_get_subsys() called while pci_devices is still empty
pci_get_subsys() called while pci_devices is still empty
pci_get_subsys() called while pci_devices is still empty
pci_get_subsys() called while pci_devices is still empty
pci_get_subsys() called while pci_devices is still empty
pci_get_subsys() called while pci_devices is still empty
pci_get_subsys() called while pci_devices is still empty
pci_get_subsys() called while pci_devices is still empty
pci_get_subsys() called while pci_devices is still empty
pci_get_subsys() called while pci_devices is still empty
pci_get_subsys() called while pci_devices is still empty
pci_get_subsys() called while pci_devices is still empty
pci_get_subsys() called while pci_devices is still empty
pci_get_subsys() called while pci_devices is still empty
PCI: Routing PCI interrupts for all devices because "pci=routeirq" specified
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
pcmcia: parent PCI bridge I/O window: 0xc000 - 0xcfff
pcmcia: parent PCI bridge Memory window: 0xcff00000 - 0xcfffffff
pcmcia: parent PCI bridge Memory window: 0x58000000 - 0x59ffffff
Yenta: CardBus bridge found at 0000:01:0b.0 [1179:0001]
Yenta: ISA IRQ mask 0x04b8, PCI irq 19
memory from /etc/pcmcia/config.opts
include memory 0xc0000-0xfffff
include memory 0xa0000000-0xa0ffffff
include memory 0x60000000-0x60ffffff
lspci:
01:0b.0 CardBus bridge: Toshiba America Info Systems ToPIC100 PCI to Cardbus
Bridge with ZV Support (rev 33)
	Bus: primary=00, secondary=01, subordinate=05, sec-latency=64
	Bus: primary=01, secondary=02, subordinate=05, sec-latency=0
Seems like same problem.
Comment 21 Thomas Nemeth 2007-07-06 07:13:22 UTC
I tested with 2.6.21 and the problem remains the same. Here are the kernel parameters I tested one by on and sometimes several at a time:
noapic nolapic irqpoll pci=assign-busses pic=routeirq pci=bios pci=biosirq pnpacpi=off acip=off
Comment 22 Thomas Nemeth 2007-07-06 07:14:19 UTC
Created attachment 11967 [details]
Boot messages for a 2.6.21 kernel
Comment 23 Natalie Protasevich 2008-03-30 18:57:39 UTC
Thomas, any luck with recent kernel? 
This problem might be related to ACPI, as well as PNP I think, so CCing to Bjorn to take a fresh look.
Comment 24 Thomas Nemeth 2008-03-31 01:08:51 UTC
(In reply to comment #23)
> Thomas, any luck with recent kernel? 

    No. But this is because I could not test them. I moved from my flat
    and could not use the offending machine since then.

    Unfortunately I don't even know if I'll be able to test further more
    kernels on that machine: I had debian installed on it with a 2.4 so
    that I could use the net to install and test new softs and kernels.
    But the last 2.6 test required me to upgrade the glibc which seems not
    to be compatible with 2.4 :(

    I need to find a small distro on CD/USB with not much resource needs.
    If you have an idea of a such a small distro, I'll be glad to use it
    for my tests.
    I'll find some time to test the last and the next ubuntu kernels if I
    can make them boot, then I'll feed again this report.


> This problem might be related to ACPI, as well as PNP I think, so CCing to
> Bjorn to take a fresh look.

    I had been trying every ACPI boot parameter. I don't know which one could
    have a positive effect...

Thanks.
Thomas.
Comment 25 Bjorn Helgaas 2008-03-31 13:13:17 UTC
I think you're using the i82365 driver in 2.4.27 but the yenta driver in 2.6.  Can you try using i82365 in 2.6?

It looks like the CardBus bridge devices (00:13.0 and 00:13.1) claim to be using PCI interrupts INTA and INTB, but we didn't find those in the ACPI _PRT.  That might be a BIOS bug, but I don't think it's the root cause here.

My PCMCIA/CardBus understanding is meager, but I think the bridge itself and devices behind the bridge (e.g., your NIC) can use different interrupts.  Your bridge claims to be generating interrupts on INTA and INTB (and we don't know what they're connected to), but I think the NIC is using IRQ 3.  My guess is that the bridge is connecting the CINT# wire from the NIC directly to the IRQ 3 input on an interrupt controller.

I don't know why yenta can't deal with this, but I wonder if i82365 can.
Comment 26 Thomas Nemeth 2008-04-02 11:57:28 UTC
(In reply to comment #25)
> I think you're using the i82365 driver in 2.4.27 but the yenta driver in 2.6. 

    From what I remember, it was yenta_socket also in 2.4.x (as it was for
    2.2.x)...


> Can you try using i82365 in 2.6?

    I tried, with a 2.6.24.2, using the slitaz distro. modprobing the
    i82365 raises an error message:
Intel ISA PCIC probe: not found.

    i82092 gives no error message, but my card is not detected. Yenta_socket
    still raises the same error messages :(
Comment 27 Thomas Nemeth 2008-06-13 12:13:56 UTC
I just tried with a 2.6.25.6 with the same results... I'm now able to build
my own kernels. Is there any particular option I could use to debug ? I
enabled debug in yenta_socket but I don't think the output is sufficient
enough to help debugging...
Comment 28 Alex Harford 2008-06-13 13:21:21 UTC
Have you tried loading the yenta_socket module with the option pwr_irqs_off=1?
Comment 29 Thomas Nemeth 2008-06-14 08:05:22 UTC
(In reply to comment #28)
> Have you tried loading the yenta_socket module with the option
> pwr_irqs_off=1?

Yes. This option is of no help unfortunately. I'll add an attachment for the
dmesg from the 2.6.25.6... I added debug output. 
Comment 30 Thomas Nemeth 2008-06-14 08:06:22 UTC
Created attachment 16475 [details]
Dmesg of 2.6.25.6 with yenta_socket module insertion.
Comment 31 Thomas Nemeth 2008-08-13 00:59:02 UTC
I have just tested the 2.6.26.2 kernel with, as usual, the same results. However, there is a bit more information I can give. On the same laptop,
with a bit old distro and a 2.2.27-pre2 kernel (which I have used for years)
the same hardware works perfectly.

The IRQs are not found as in recent kernels, so it does not seem the problem
comes from here. I checked the modules loaded: the i82365 is the one used by
this old kernel.
So I loaded this module on the 2.6.26.2 kernel and the result is here:
Intel ISA PCIC probe: not found.
FATAL: Error inserting i82365 (/lib/modules/2.6.26.2-slitaz/kernel/drivers/pcmcia/i82365.ko): No such device

I'll give more information on the 2.2.27-pre2...
Comment 32 Thomas Nemeth 2008-08-13 01:00:30 UTC
Created attachment 17204 [details]
Boot messages of 2.2.27-pre2
Comment 33 Thomas Nemeth 2008-08-13 01:01:19 UTC
Created attachment 17205 [details]
Modules list for 2.2.27-pre2
Comment 34 Thomas Nemeth 2008-08-13 01:02:14 UTC
Created attachment 17206 [details]
List of interruptions for 2.2.27-pre2
Comment 35 Thomas Nemeth 2008-08-13 01:03:25 UTC
Created attachment 17207 [details]
List of PCI devices for 2.2.27-pre2
Comment 36 Thomas Nemeth 2008-08-13 01:10:51 UTC
Created attachment 17208 [details]
IO ports for 2.2.27-pre2
Comment 37 Thomas Nemeth 2008-08-22 23:49:08 UTC
I've just made some other tests. I was wrong when I previously said that in 2.2.x it was yenta: it really was i82365. And it worked without PCI IRQs
numbers as shown in the boot messages. But with 2.4.x and 2.6.x it really is
yenta: i82365 does not support PCI devices -- and in particular ToPIC97
(PCI-to-CardBus) -- but only ISA devices !
Comment 38 Thomas Nemeth 2008-08-23 06:44:01 UTC
Created attachment 17385 [details]
Boot messages of 2.4.22

The boot messages of a 2.4.22 kernel show that kernels 2.4 correctly recognize the ToPIC97 pcmcia Cardbus adapter
Comment 39 Thomas Nemeth 2008-08-23 06:45:50 UTC
Created attachment 17386 [details]
List of modules for 2.4.22

The modules list shows that the pcmcia module used for the recognized pcmcia chipset is really yenta_socket.
Comment 40 Thomas Nemeth 2008-08-23 06:46:48 UTC
Created attachment 17387 [details]
PCI listing for 2.4.22

Additionnal information about PCI listing regarding the pcmcia adapter.
Comment 41 Thomas Nemeth 2008-08-23 06:47:27 UTC
Created attachment 17388 [details]
IO mem for 2.4.22
Comment 42 Thomas Nemeth 2008-08-23 06:47:45 UTC
Created attachment 17389 [details]
IO ports for 2.4.22
Comment 43 Thomas Nemeth 2008-08-23 08:26:19 UTC
I modified a little the yenta_socket module just to see what would happen if
CardBus support disabling -- when no IRQ is found -- was dropped (see the patch in the next attachment).
The pcmcia chipset is then correctly recognised, and my pcmcia eth card is
too. But I couldn't set its IP address (see strace in further attachement).
Comment 44 Thomas Nemeth 2008-08-23 08:26:53 UTC
Created attachment 17395 [details]
Patch to force CardBus support in yenta socket even when no IRQ is found.
Comment 45 Thomas Nemeth 2008-08-23 08:28:20 UTC
Created attachment 17396 [details]
Boot messages of 2.6.26.2 with yenta patch applied
Comment 46 Thomas Nemeth 2008-08-23 08:28:59 UTC
Created attachment 17397 [details]
Strace dump when calling ifconfig when yenta patch is applied
Comment 47 Thomas Nemeth 2008-08-23 08:43:31 UTC
Comment on attachment 17396 [details]
Boot messages of 2.6.26.2 with yenta patch applied

boot messages cluttered by several insmod/modprobe attempts... please ignore this one. Sorry.
Comment 48 Thomas Nemeth 2008-08-23 08:44:52 UTC
Created attachment 17399 [details]
Boot messages of 2.6.26.2 with yenta patch applied
Comment 49 Komuro 2008-09-22 18:58:19 UTC
It seems the pcmcia-cs uses special technique for the cardbus-bridge
that can't get the irq.

Currently, no one is working at such old PC for kernel 2.6.x.
I recommend you buy a new PC.



>tulip0:  MII transceiver #1 config 3100 status 7849 advertising 05e1.
>eth0: ADMtek Comet rev 17 at Port 0x1800, 00:14:00:00:3e:79, IRQ 0.

tulip0 is working at polling mode...
Comment 50 Thomas Nemeth 2008-09-23 04:23:38 UTC
(In reply to comment #49)
> It seems the pcmcia-cs uses special technique for the cardbus-bridge
> that can't get the irq.

    Certainly. The real question is: which one :)


> Currently, no one is working at such old PC for kernel 2.6.x.
> I recommend you buy a new PC.

    I already have a new PC. That's not the answer I wanted to have. I
    like using old computers (I have some old Sparcs, MacIntoshes and even
    an AS400). And, from what I heard on recent news, support for old
    computers is not planned for removal.

    I don't have much time. I'll try and see what I can do to bring that
    pcmcia chipset to work but I need help.

Thomas.
Comment 51 Dominik Brodowski 2010-03-06 14:07:42 UTC
Hm, it looks to me that the PCI IRQ pins are routed to IRQ #11. So what about trying out (at first) some workaround: Could you replace the line in drivers/pcmcia/yenta_socket.c - function yenta_probe() which states:
	socket->cb_irq = dev->irq;
with:
	socket->cb_irq = 11;
?

Also, some quite new patches (see:
http://www.mail-archive.com/linux-pcmcia@lists.infradead.org/msg02903.html
http://www.mail-archive.com/linux-pcmcia@lists.infradead.org/msg02904.html
http://www.mail-archive.com/linux-pcmcia@lists.infradead.org/msg02906.html
) which currently are only for some TI bridge might be generalized to work also in other cases where the PCI IRQ is 0. I'll dig into that later.
Comment 52 Thomas Nemeth 2010-03-13 08:29:02 UTC
> --- Comment #51 from Dominik Brodowski <linux@brodo.de>  2010-03-06 14:07:42
> ---
> Hm, it looks to me that the PCI IRQ pins are routed to IRQ #11. So what about
> trying out (at first) some workaround: Could you replace the line in
> drivers/pcmcia/yenta_socket.c - function yenta_probe() which states:
>    socket->cb_irq = dev->irq;
> with:
>    socket->cb_irq = 11;
> ?

    It seems that forcing the irq number does not change anything :(
    I tested that oneliner on the 2.6.25.6 (since it's the one I already had
    under my hand at that time) and there are still the same messages.


> Also, some quite new patches (see:
> http://www.mail-archive.com/linux-pcmcia@lists.infradead.org/msg02903.html
> http://www.mail-archive.com/linux-pcmcia@lists.infradead.org/msg02904.html
> http://www.mail-archive.com/linux-pcmcia@lists.infradead.org/msg02906.html
> ) which currently are only for some TI bridge might be generalized to work
> also
> in other cases where the PCI IRQ is 0. I'll dig into that later.

    Should I use a more recent kernel or can I continue going on with 2.6.25.6 ?

    Using a recent kernel may take me some time since there's no network on
    that machine (the network only comes through pcmcia :( ).

    Anyway, thank you very much ! I was desperating that someone might have
    a look at my problem...


Thomas.
Comment 53 Thomas Nemeth 2010-03-13 09:35:19 UTC
I was wrong.

It indeed changed something. My PCMCIA eth device has been recognized once I
inserted the yenta_socket module. Still the IRQ at boot time is not detected,
but now, at least, I have something close to a working state. The eth device
seems to be recognized but the network refuses to communicate.

Moreover the patches don't apply to either 2.6.32.9 or 2.6.33 (there are some
badly placed newlines in the webpages containing the patches. I tried to
correct most of them but I don't know if I did them all).

I'll send you some more boot logs with 2.6.25.6 and 2.6.33, and then I'll
try to apply the patches by hand.
Comment 54 Thomas Nemeth 2010-03-13 09:47:53 UTC
Created attachment 25494 [details]
Boot messages for 2.6.25.6 with IRQ forced to 11.

Here is the bootlog of the 2.6.25.6 kernel with the yenta_socket IRQ forced to
11. There is clearly some improvements here since I can have an ethernet device
when I plugin the pcmcia eth card. However I still cannot send pings through the
network.
Comment 55 Dominik Brodowski 2010-03-13 10:31:45 UTC
What happens if you eject and insert the card multiple times? Is this recognized?
Comment 56 Thomas Nemeth 2010-03-13 10:45:02 UTC
Created attachment 25495 [details]
Boot messages for 2.6.33 with IRQ forced to 11.
Comment 57 Thomas Nemeth 2010-03-13 10:49:04 UTC
Created attachment 25496 [details]
Boot messages for 2.6.33 with IRQ forced to 3...

As in the previous kernels messages I had seen that the IRQ used was IRQ3,
this time, instead of 11, I forced the IRQ to 3. However, this did not
worked as expected :)
Comment 58 Thomas Nemeth 2010-03-13 11:24:39 UTC
(In reply to comment #55)
> What happens if you eject and insert the card multiple times? Is this
> recognized?

    Yes. Each time I insert back the card, eth0 is recognized the same.
Comment 59 Thomas Nemeth 2010-03-13 12:58:19 UTC
Created attachment 25497 [details]
Boot messages for 2.6.33 with the 3 pcmcia specified patches in comment #51

I applied by hand the patches from comment #51, but the result is a bit
buggy. From the context shown in the original patches, I can see that the
code from 2.6.33 is not the one these patches apply on.

I'll make my patches available in another attachment if needed.
Comment 60 Dominik Brodowski 2010-03-13 16:52:30 UTC
Okay, to summarize:

- forcing IRQ to be 11 means the CardBus bridge works as it should -- it recognizes card insert and eject events properly.

-  the CardBus network card does not work, though.

I'm not surprised at all that the patches in comment #51 do not work -- they are for a different, but still similar problem. What I'd be interested now is the output of the "cbdump" tool (part of pcmciautils, pcmcia-cs) both under a working and a non-working kernel. Maybe we need to set some register properly for the hard override to work.
Comment 61 Thomas Nemeth 2010-03-14 09:33:56 UTC
Created attachment 25507 [details]
cbdump for 2.6.26.2

This is the output of cbdump for a not-working 2.6.26.2 kernel.
Comment 62 Thomas Nemeth 2010-03-14 09:37:09 UTC
Created attachment 25508 [details]
cbdump for 2.6.33

This is the output of cbdump for the 2.6.33 kernel modified with the
IRQ forced to 11. Although I cannot ping other computers on the network,
it may be the best option by now. I'll investigate to see if it's not a
router related problem.

I can't make a 2.4.27 load the yenta_socket driver anymore with the old
debian sarge install CD.
Comment 63 Thomas Nemeth 2010-03-14 09:57:08 UTC
After having done tests the 2.6.33 with the IRQ forced to 11 really
does not work. It's not a router related problem.

The 2.2.27 kernel is too old to run cbdump :(

I'll try to have a 2.4 working kernel again.
Comment 64 Dominik Brodowski 2010-03-14 10:02:44 UTC
Does "lspci -vvxxx" work on a 2.2.27 kernel? Maybe the difference between the output of "lspci -vvxxx" on 2.2.27 and 2.6.33 does help enough to make it work?
Comment 65 Thomas Nemeth 2010-03-14 11:03:31 UTC
Created attachment 25509 [details]
output of lspci -vvxxx on 2.6.33

This is the output of the lspci -vvxxx command on the 2.6.33 kernel. I'm
not skilled enough to know what means the hexdump.
Comment 66 Thomas Nemeth 2010-03-14 11:10:17 UTC
Created attachment 25510 [details]
output of lspci -H 2 -vvxxx on 2.2.27

I had to make a direct hardware access.
Comment 67 Thomas Nemeth 2010-03-14 11:15:32 UTC
(In reply to comment #64)
> Does "lspci -vvxxx" work on a 2.2.27 kernel? Maybe the difference between the
> output of "lspci -vvxxx" on 2.2.27 and 2.6.33 does help enough to make it
> work?

    As you can see, unfortunately, it's not sufficient... At least for me.
    The only thing I can observe is that with the 2.2.27 kernel, my network
    adapter is seen as a pci device though it's not even seen by the 2.6.33.
Comment 68 Dominik Brodowski 2010-03-14 12:52:34 UTC
Could you repeat the "cbdump" on (plain) 2.6.33 with IRQ forced to 11, and the network card inserted?
Comment 69 Thomas Nemeth 2010-03-14 13:03:10 UTC
(In reply to comment #68)
> Could you repeat the "cbdump" on (plain) 2.6.33 with IRQ forced to 11, and
> the
> network card inserted?

    It should already be the one in attachment 25508 [details] (see Comment #62 for more).
Comment 70 Dominik Brodowski 2010-03-14 13:11:52 UTC
While I'm checking the cbdump output: are you sure the "tulip" driver is the correct one for this card? There seem to be some mis-assignments in the past ( https://bugs.launchpad.net/ubuntu/+source/udev/+bug/48026 ), that's why I ask...
Comment 71 Dominik Brodowski 2010-03-14 13:26:20 UTC
and next question: Are there two CardBus/PCMCIA slots? If so, might the other one work? (The I365_ settings for slot 0 seem much more appropriate than the ones for slot 1)
Comment 72 Thomas Nemeth 2010-03-14 13:37:01 UTC
(In reply to comment #70)
> While I'm checking the cbdump output: are you sure the "tulip" driver is the
> correct one for this card? There seem to be some mis-assignments in the past
> (
> https://bugs.launchpad.net/ubuntu/+source/udev/+bug/48026 ), that's why I
> ask...

    It was the one used by 2.2.27 and 2.4.22 as show in attachment 17205 [details] and
    in attachment 17386 [details] but may be has it changed since then ?

    The only difference, module-related, between a working and a current
    non-working kernel is that the 2.2.27 used the i82365 driver and now
    only the yenta_socket seems to recognize the device.
Comment 73 Thomas Nemeth 2010-03-14 13:42:17 UTC
(In reply to comment #71)
> and next question: Are there two CardBus/PCMCIA slots? If so, might the other
> one work? (The I365_ settings for slot 0 seem much more appropriate than the
> ones for slot 1)

    Oh !

    You got it right !!!

    That's strange, but now, with 2.6.33 and the yenta_socket IRQ forced to
    11, the card when put into the slot 0 works !

    I'm more that happy to know that.
Comment 74 Dominik Brodowski 2010-03-14 14:43:16 UTC
Excellent news. Is this result sufficient for you? If so, I'd suggest closing the bug as WONTFIX. Otherwise, we'd first need to create a DMI-based quirk so that IRQ is set to 11; and then debug why the second slot does not work, while the first one does.
Comment 75 Thomas Nemeth 2010-03-14 16:40:24 UTC
(In reply to comment #74)
> Excellent news. Is this result sufficient for you? If so, I'd suggest closing
> the bug as WONTFIX. Otherwise, we'd first need to create a DMI-based quirk so
> that IRQ is set to 11; and then debug why the second slot does not work,
> while
> the first one does.

    I'm ready for the full debug session, if you don't mind, so that the
    fixes are available in distributions, espacially those targeted for
    old hardware. But if you want to let it in this state, I'm fine with
    it, I'll just have to recompile new kernels each time... Or make my
    own distro :)
Comment 76 Dominik Brodowski 2010-03-15 07:42:23 UTC
That's good news. To create the DMI-based quirk, we'd first need a "dmidecode" output. For the other problem(s), I need to dig into some documentation and 2.4 source code first...
Comment 77 Thomas Nemeth 2010-03-17 12:07:40 UTC
(In reply to comment #76)
> That's good news. To create the DMI-based quirk, we'd first need a
> "dmidecode"
> output. For the other problem(s), I need to dig into some documentation and
> 2.4
> source code first...

   Ok. I'll provide you this information. Is there anything special needed
   to look for in the output ?
Comment 78 Thomas Nemeth 2010-03-17 19:24:47 UTC
Created attachment 25571 [details]
dmidecode output on 2.6.33 with IRQ 11 forced.

Here we have a problem.

dmidecode did not produce any output. On my work desktop, dmidecode worked
nice producing a lot of output, but on the target machine, nothing came out.
Just this message saying that it found nothing.

I have compiled the other softs in the dmidecode package. If you need some
more information, just tell me.
Comment 79 Dominik Brodowski 2010-03-22 19:15:49 UTC
Regarding the dmidecode output: do you have CONFIG_DMI and CONFIG_DMIID enabled in the kernel? Using a dmi-code is the preferred way to specify an override.

Also, could you re-run cbdump, please, with kernel 2.6.34-rc2 and the following fix-up:

socket->cb_irq = 11;
dev->irq = 11;

first inserted into the working socket #1, then into the non-working socket #0? Thanks!
Comment 80 Thomas Nemeth 2010-03-24 20:08:56 UTC
Created attachment 25689 [details]
Boot messages for 2.6.34-rc2 with IRQ forced to 11.

As you requested I compiled a 2.6.34-rc2 kernel with the irqs forced to 11.
The configuration file displays:
$ grep CONFIG_DMI linux-2.6.34-rc2/.config
CONFIG_DMI=y
CONFIG_DMIID=y

It was the same with the 2.6.33 :(
I booted and configuered the eth card in the working slot, tested it (ok) and
then put it in the other (non-working) slot. It could get an IP address through
DHCP but ping didn't work.

dmidecode gave the same results as previouly.
Comment 81 Thomas Nemeth 2010-03-24 20:16:34 UTC
Ooops wrong.
I didn't get an IP address through DHCP on the non-working slot. I just
forgot to ifconfig down the interface before switching slots. The non-working
slot still doesn't work.

Regarding the dmidecode output, could it be that my computer is too old ?
Comment 82 Dominik Brodowski 2010-03-25 18:15:13 UTC
This is with both
socket->cb_irq = 11;
dev->irq = 11;
?

What's the cbdump output of each socket, with the card inserted? (I'm asking as one bit which should be set to 0 is set to 1 in the last cbdump output, and that confuses me)
Comment 83 Thomas Nemeth 2010-03-26 21:18:34 UTC
Created attachment 25724 [details]
Output of cbdump on 2.6.34-rc2 with the eth card in the non-working slot
Comment 84 Thomas Nemeth 2010-03-26 21:20:02 UTC
Created attachment 25725 [details]
Output of cbdump on 2.6.34-rc2 with the eth card in the working slot
Comment 85 Thomas Nemeth 2010-03-26 21:23:40 UTC
(In reply to comment #82)
> This is with both
> socket->cb_irq = 11;
> dev->irq = 11;
> ?

    Yes.

thomas@cixi:exether$ grep "= 11;" linux-2.6.34-rc2/drivers/pcmcia/yenta_socket.c
        socket->cb_irq = 11;
        dev->irq = 11;


> What's the cbdump output of each socket, with the card inserted? (I'm asking
> as one bit which should be set to 0 is set to 1 in the last cbdump output,
> and that confuses me)

    Here is the diff between the two dumps (hope this helps):

thomas@cixi:~$ diff cbdump-2.6.34-rc2-slitaz-nonworkingslot cbdump-2.6.34-rc2-slitaz-workingslot
--- cbdump-2.6.34-rc2-slitaz-nonworkingslot     2010-03-26 22:15:39.000000000 +0100
+++ cbdump-2.6.34-rc2-slitaz-workingslot        2010-03-26 22:15:40.000000000 +0100
@@ -12,20 +12,20 @@
   IO Limit 0                     [30] : 0x000018fc
   IO Base 1                      [34] : 0x00001c00
   IO Limit 1                     [38] : 0x00001cfc
-  Bridge control                 [3e] : 0x0500
+  Bridge control                 [3e] : 0x0580
   Subsystem vendor ID            [40] : 0x1179
   Subsystem device ID            [42] : 0x0001
   Legacy mode base               [44] : 0x0001
   -- cardbus registers
   CB_SOCKET_EVENT                [00] : 0x00000000
   CB_SOCKET_MASK                 [04] : 0x00000006
-  CB_SOCKET_STATE                [08] : 0x30000828
+  CB_SOCKET_STATE                [08] : 0x30000007
   CB_SOCKET_FORCE                [0c] : 0x00000000
-  CB_SOCKET_CONTROL              [10] : 0x00000033
+  CB_SOCKET_CONTROL              [10] : 0x00000000
   CB_SOCKET_POWER                [20] : 0x00000000
   -- exca registers
   I365_IDENT                     [00] : 0x83
-  I365_STATUS                    [01] : 0x8e
+  I365_STATUS                    [01] : 0xb2
   I365_POWER                     [02] : 0x40
   I365_INTCTL                    [03] : 0x40
   I365_CSC                       [04] : 0x00
@@ -73,20 +73,20 @@
   IO Limit 0                     [30] : 0x000010fc
   IO Base 1                      [34] : 0x00001400
   IO Limit 1                     [38] : 0x000014fc
-  Bridge control                 [3e] : 0x0580
+  Bridge control                 [3e] : 0x0500
   Subsystem vendor ID            [40] : 0x1179
   Subsystem device ID            [42] : 0x0001
   Legacy mode base               [44] : 0x0001
   -- cardbus registers
   CB_SOCKET_EVENT                [00] : 0x00000000
   CB_SOCKET_MASK                 [04] : 0x00000006
-  CB_SOCKET_STATE                [08] : 0x30000087
+  CB_SOCKET_STATE                [08] : 0x30000828
   CB_SOCKET_FORCE                [0c] : 0x00000000
-  CB_SOCKET_CONTROL              [10] : 0x00000000
+  CB_SOCKET_CONTROL              [10] : 0x00000033
   CB_SOCKET_POWER                [20] : 0x00000000
   -- exca registers
   I365_IDENT                     [00] : 0x83
-  I365_STATUS                    [01] : 0xb2
+  I365_STATUS                    [01] : 0x8e
   I365_POWER                     [02] : 0x40
   I365_INTCTL                    [03] : 0x40
   I365_CSC                       [04] : 0x00
thomas@cixi:~$
Comment 86 Dominik Brodowski 2010-03-27 14:00:09 UTC
Created attachment 25735 [details]
test patch to use ISA IRQs also for CardBus

That's bad news -- both sockets are configured the same way. So they _should_ behave the same way, and work... Well, could you remove the IRQ=11 forced setting, try out the attached patch (both sockets), and send the dmesg (even if it works)? cbdump or other is not needed.
Comment 87 Thomas Nemeth 2010-03-28 09:58:35 UTC
Created attachment 25738 [details]
Boot messages for 2.6.34-rc2 with applied patch

No slot worked :(
Comment 88 Dominik Brodowski 2010-03-28 11:54:21 UTC
Thanks. Both sockets look properly configured (for PCI IRQ = 11); the workaround (trying to use ISA IRQs for PCI) does not work as expected -- at least from what I determine out of the ToPIC97 datasheet found at the pcmcia-cs homepage. :(
Comment 89 Thomas Nemeth 2010-03-30 20:05:42 UTC
I often have to read datasheets. Mainly for touchscreens, I2C devices and some
other external devices. However, reading through the ToPIC97 datasheet gave me
headaches :(

What can I do now, in order to help you ?
Comment 90 Thomas Nemeth 2010-03-30 20:12:34 UTC
Created attachment 25766 [details]
Patch to force IRQ number as a module parameter.

I know this is not the ideal solution for this problem. Probing would be way
better to handle this, but in the end, if we can't, there's still this handy
solution...

And it's not very intrusive ;) It applies against the 2.6.34-rc2.

Still it does not fix the problem with the non-working slot, of course :(

However what about the 2.2.x code used to detect the IRQ ? Extracting the used
algorithm should be rather difficult mainly due to kernel architecture changes
but it used to work.
Comment 91 Dominik Brodowski 2010-03-31 06:45:07 UTC
The problem isn't detecting the IRQ -- we can use ISA IRQ 3 (as 2.2.xx did) or ISA IRQ 9 and 10 (as the patch in comment #86 did).

The problem is setting up the bridge so that it routes CSC (card status change) IRQs for CardBus and 16bit cards to the ISA IRQ and also card IRQs for CardBus and 16bit cards to the ISA IRQ. This seems to be impossible on the ToPIC97.

However, 2.2. seems to do some "polling" to get the IRQs right. I.e., it isn't really using the IRQs, but polls whether an IRQ occured. That seems necessary at least or the CSC interrupt.
Comment 92 Jonathan Nieder 2012-01-29 21:01:42 UTC
Dominik Brodowski wrote:

> The problem isn't detecting the IRQ -- we can use ISA IRQ 3 (as 2.2.xx did)
> or
> ISA IRQ 9 and 10 (as the patch in comment #86 did).
>
> The problem is setting up the bridge so that it routes CSC (card status
> change)
> IRQs for CardBus and 16bit cards to the ISA IRQ and also card IRQs for
> CardBus
> and 16bit cards to the ISA IRQ. This seems to be impossible on the ToPIC97.
>
> However, 2.2. seems to do some "polling" to get the IRQs right. I.e., it
> isn't
> really using the IRQs, but polls whether an IRQ occured. That seems necessary
> at least or the CSC interrupt.

Hm, so what's the next step (if any)?

Just for completeness: Thomas tested[1] with 3.0 and symptoms are still present.

[1] http://bugs.debian.org/366507#108
Comment 93 Dominik Brodowski 2012-02-10 15:28:27 UTC
Well, one slot seems to work with the (technically) intrusive patch which forces the IRQ to 11, right? If so, I'd propose to keep it this way -- and keep this patch outside of mainline. Also, a DMI-based override won't work for this machine (strangely) does not report any DMI information at all.
Comment 94 Jonathan Nieder 2012-02-15 23:28:51 UTC
Thomas, do you have a patch that works for you against 3.2.y?

If so, then I'd suggest putting it in Documentation/pcmcia/ with a note on the issue and calling it done. Or if it is possible to add a kernel command line option for this with a not-too-intrusive patch, that might be another way. I just don't like the idea of someone being stuck on an old kernel because of their hardware.
Comment 95 Thomas Nemeth 2012-02-16 13:01:58 UTC
(In reply to comment #94)
> Thomas, do you have a patch that works for you against 3.2.y?

    I don't, but I can make one. My previous patch was only a few lines. I
    think it still can apply:

$ patch -p1 < /home/thomas/pcmcia_yenta_force_irq.patch
patching file drivers/pcmcia/yenta_socket.c
Hunk #1 succeeded at 36 (offset -1 lines).
Hunk #2 succeeded at 1223 (offset -2 lines).


    However, it does not use the kernel command line. Should not be hard
    to add...