Most recent kernel where this bug did not occur: 2.6.12.x (dont know what about 2.6.13.x, didn't use them) Distribution: PLD Hardware Environment: IBM ThinkPad 600E Software Environment: gcc 3.3.6, binutils 2.15.94.0.2.2, pcmcia-cs 3.2.8-6 Problem Description: Problem is about this pcmcia card: vers_1 5.0, "Xircom", "CreditCard Ethernet 10/100 + Modem 56", "CEM56" running on xirc2ps_cs module. It worked perfectly on 2.6.12.x series. After upgrade it stopped, module is loaded properly, card is detected, even mii-tools shows link on it, but it behaves exactly like the wire would be unplugged. DHCP times out, every communication attempt (with address set by hand) gives "destination host unreachable". Another 16bit pcmcia card (orinoco_cs) works perfectly on this kernel so i suppose its driver problem, not pcmcia subsystem which i know has been changed recently (tried it with pcmciautils, behaves the same). Steps to reproduce:
kernel: pcmcia: xirc2ps_cs lacks a requisite callback function Found this in dmesg if that matters.
Is this still a problem in 2.6.15-rc5? I can't reproduce this warning here, and the necessary change got into xirc2ps_cs at the same time as all other PCMCIA drivers... so I'm a bit surprised about this bug report. Or do you use an out-of-tree version of it?
Its still not working on 2.6.15-rc5, its even worse cause i dont even get eth0 created (i had it created, though not working on 2.6.14) From dmesg: Yenta: CardBus bridge found at 0000:00:02.0 [1014:00eb] 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:00:02.0, mfunc 0xfba97543, devctl 0x62 Yenta: ISA IRQ mask 0x0498, PCI irq 11 Socket status: 30000006 PCI: Found IRQ 11 for device 0000:00:02.1 Yenta: CardBus bridge found at 0000:00:02.1 [1014:00eb] Yenta: Using CSCINT to route CSC interrupts to PCI Yenta: Routing CardBus interrupts to PCI Yenta TI: socket 0000:00:02.1, mfunc 0xfba97543, devctl 0x62 Yenta: ISA IRQ mask 0x0498, PCI irq 11 Socket status: 30000010 cs: IO port probe 0x3d4-0x4ff: excluding 0x3ec-0x403 0x4cc-0x4d3 cs: IO port probe 0x3c0-0x3d2: clean. cs: IO port probe 0x100-0x3af: excluding 0x130-0x137 0x200-0x207 0x220-0x22f 0x388-0x38f cs: IO port probe 0xc00-0xcff: clean. cs: IO port probe 0x800-0x8ff: clean. cs: IO port probe 0xa00-0xaff: clean. cs: IO port probe 0x3d4-0x4ff: excluding 0x3ec-0x403 0x4cc-0x4d3 cs: IO port probe 0x3c0-0x3d2: clean. cs: IO port probe 0x100-0x3af: excluding 0x130-0x137 0x200-0x207 0x220-0x22f 0x388-0x38f cs: IO port probe 0xc00-0xcff: clean. cs: IO port probe 0x800-0x8ff: clean. cs: IO port probe 0xa00-0xaff: clean. NET: Registered protocol family 23 pccard: PCMCIA card inserted into slot 1 cs: memory probe 0xa0000000-0xa0ffffff: excluding 0xa0000000-0xa0ffffff cs: memory probe 0x60000000-0x60ffffff: clean. pcmcia: registering new device pcmcia1.0 pcmcia: registering new device pcmcia1.1 1.1: ttyS3 at I/O 0x2e8 (irq = 3) is a 16550A xirc2ps_cs: no ports available Everything seems to be ok but the last line. Modem (created as ttyS3 - serial_cs) on this device seems to work fine. On 2.6.15-rc5 orinoco_cs seems to work fine (cant test it fully due to lack of wifi network atm, but the device is created and is looking for a network for quite a long time before timeout so i think it'd work ok just like before) The strange thing is i get in dmesg: pcmcia: Detected deprecated PCMCIA ioctl usage. pcmcia: This interface will soon be removed from the kernel; please expect breakage unless you upgrade to new tools. pcmcia: see http://www.kernel.org/pub/linux/utils/kernel/pcmcia/pcmcia.html for details. I have no idea what triggers it, I'm not using pcmcia-cs anymore (i dont even have it installed now). pcmciautils 010 build with udev support on 075 version. I think its not a problem though cause i get this warning on working orinoco too. Checked also that it was 2.6.13 where xirc2ps_cs stopped working (on the lastest 2.6.12.x still worked ok).
And on the last question, i dont use out of box version of this driver. Patches i might use dont touch this driver or whole PCMCIA subsystem at all.
Could you post the output of "cardctl ident" and "cardctl info", please?
# pccardctl info PRODID_1="" PRODID_2="" PRODID_3="" PRODID_4="" MANFID=0000,0000 FUNCID=255 PRODID_1="Xircom" PRODID_2="CreditCard Ethernet 10/100 + Modem 56" PRODID_3="CEM56" PRODID_4="1.00" MANFID=0105,110a FUNCID=2 # sudo /sbin/pccardctl ident Socket 0: no product info available Socket 1: product info: "Xircom", "CreditCard Ethernet 10/100 + Modem 56", "CEM56", "1.00" manfid: 0x0105, 0x110a function: 2 (serial)
Could you please re-test with a recent kernel, and post the output of "pccardctl status" (needs pcmciautils-012)?
kernel 2.6.15.1, pcmciautils 012 dmesg exactly as above (with xirc2ps_cs: no ports available, and no eth created) # /sbin/pccardctl status Socket 0: no card Socket 1: 5.0V 16-bit PC Card Subdevice 0 (function 0) bound to driver "xirc2ps_cs" Subdevice 1 (function 0) bound to driver "serial_cs" btw, the ,,status'' parameter works also from non-root user but the output is different: $ /sbin/pccardctl status Socket 0: no card Socket 1: no card No error, no warning, this can be a little misleading.
OK, so the device is correctly bound to the driver; the core knows about what ports are available -- in short, everything _seems_ to be prepared just well for the xirc2ps driver. However, it fails... really really strange. So, let's try something equally strange. Could you compile the xirc2ps driver into the kernel, while building serial_cs as a module -- or, even better, not building it at all? I'm wondering whether the ordering of the two functions being bound to drivers changes something...
Created attachment 7052 [details] delay adding of second device If we're lucky, this patch solves this problem "out of the box", i.e. no fiddling with the configuration (as suggested in previous comment) is necessary.
Sorry it took so long, lack of time. After applying this patch device (eth0) is created but still no reply for dhcp request. mii-tool shows link. So we're back to the situation from 2.6.14. I'll check later on the other side if this dhcp request is really sended. Didn't check the module static compilation.
Created attachment 7165 [details] only register second device after first one is configured Could you check the effects of this patch (instead of the previous one), please?
Big appologize for not replaying last time, had to get it work fast at that point and changed netcard. Anyway, tried this xirc2ps on 2.6.16.20 and still the same. I checked it with tcpdump, it shows BOOTP/DHCP requests being sent (or arp queries when i give him static IP) but no replay, mii-tool shows link properly. Should i adapterize (id=7165) patch for new kernel and try now?
Does dmesg still contain "xirc2ps_cs: no ports available"?
pcmcia: registering new device pcmcia1.0 eth%d: MII link partner: 05e1 eth%d: MII selected eth%d: media 100BaseT, silicon revision 5 eth0: Xircom: port 0x300, irq 3, hwaddr 00:10:A4:EA:01:AB pcmcia: registering new device pcmcia1.1 1.1: ttyS3 at I/O 0x2e8 (irq = 3) is a 16550A (...) eth0: MII link partner: 05e1 eth0: MII selected eth0: media 100BaseT, silicon revision 5 kernel 2.6.16.23 I had a very similar card for a moment (also xirc2ps_cs) but without builtin modem, and it was not working as well, in exactly the same way.
I am having the same problem with kernel versions 2.6.18 and 2.6.21.1. On kernel version 2.6.8 things work fine. I am also using Thinkpad 600E, with a Xircom CreditCard CE3-10/100 RE-100 card (pcmcia). The xirc2ps_cs module loads fine and acts like the card is working, however, data doesn't get received over the wire. (Interestingly, data *does* get sent, as detected by running tcpdump on the far end of the wire.) I have reported further details at http://bugs.debian.org/418814, and I'd be glad to provide further information at your request. Thanks, Paul Dexter
Any progress with the bug, is the card working with newest kernels? Thanks.