Multi-function pcmcia card: only function 0 detected.

Bug #52510 reported by Romano Giannetti on 2006-07-10
2
Affects Status Importance Assigned to Milestone
Debian
New
Undecided
Unassigned
Fedora
Fix Released
Medium
linux-source-2.6.17 (Ubuntu)
Medium
Unassigned

Bug Description

Binary package hint: pcmciautils

I know this bug-report has quite few data. I will add lspci -vv and more information as requested later.

Basically, I have a 3com/Megahertz pcmcia card which has an ethernet and a modem into it. A freshly installed ubuntu did not recognize it at all. Then digging a bit I did:

cp /etc/pcmcia/cis/3CXEM556.dat /lib/firmware/3CXEM556.cis

and now (after pccardctl eject / insert) the function 0, ethernet, is recognized and working. Unfortunately the modem function (which is the one I really need) is not working. I tried loading serial_cs, but tat did not do the trick.

The card worked perfectly in mandriva 2005, which I wiped out
to install Dapper... ;-)

Download full text (4.4 KiB)

I have dmesgs for the case of working (in Mandriva) and not working (in Ubuntu dapper).

Working:
[17179598.448000] ACPI: PCI Interrupt 0000:00:0a.0[A] -> Link [LNKA] ->
GSI 9 (level, low) -> IRQ 9
[17179598.448000] Yenta: CardBus bridge found at 0000:00:0a.0
[104d:80f6]
[17179598.448000] Yenta: Enabling burst memory read transactions
[17179598.448000] Yenta: Using CSCINT to route CSC interrupts to PCI
[17179598.448000] Yenta: Routing CardBus interrupts to PCI
[17179598.448000] Yenta TI: socket 0000:00:0a.0, mfunc 0x012c1222,
devctl 0x66
[17179598.680000] Yenta: ISA IRQ mask 0x0808, PCI irq 9
[17179598.680000] Socket status: 30000006
[17179598.692000] ACPI: PCI Interrupt 0000:00:0a.1[B] -> Link [LNKB] ->
GSI 10 (level, low) -> IRQ 10
[17179598.692000] Yenta: CardBus bridge found at 0000:00:0a.1
[104d:80f6]
[17179598.692000] Yenta: Using CSCINT to route CSC interrupts to PCI
[17179598.692000] Yenta: Routing CardBus interrupts to PCI
[17179598.692000] Yenta TI: socket 0000:00:0a.1, mfunc 0x012c1222,
devctl 0x66
[17179598.924000] Yenta: ISA IRQ mask 0x0808, PCI irq 10
[17179598.924000] Socket status: 30000010
[17179599.872000] cs: IO port probe 0xc00-0xcff: clean.
[17179599.872000] cs: IO port probe 0xc00-0xcff: clean.
[17179599.872000] cs: IO port probe 0x100-0x4ff: excluding 0x378-0x37f
0x4d0-0x4d7
[17179599.876000] cs: IO port probe 0x100-0x4ff: excluding 0x378-0x37f
0x4d0-0x4d7
[17179599.880000] cs: IO port probe 0xa00-0xaff: clean.
[17179599.880000] cs: IO port probe 0xa00-0xaff: clean.
[17179599.920000] cs: memory probe 0xa0000000-0xa0ffffff: clean.
[17179600.732000] eth1: 3Com 3c589, io 0x300, irq 3, hw_addr
00:00:86:1A:4E:A8
[17179600.732000] 8K FIFO split 5:3 Rx:Tx, auto xcvr
[17179600.776000] ttyS1 at I/O 0x2f8 (irq = 10) is a 16550A

Not working (ubuntu dapper):

[17179598.628000] Yenta: CardBus bridge found at 0000:00:0a.0
[104d:80f6]
[17179598.628000] Yenta: Using CSCINT to route CSC interrupts to PCI
[17179598.628000] Yenta: Routing CardBus interrupts to PCI
[17179598.628000] Yenta TI: socket 0000:00:0a.0, mfunc 0x012c1222,
devctl 0x66
[17179598.788000] **** SET: Misaligned resource pointer: d961bb22 Type
07 Len 0
[17179598.788000] ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 5
[17179598.788000] PCI: setting IRQ 5 as level-triggered
[17179598.788000] ACPI: PCI Interrupt 0000:00:07.5[C] -> Link [LNKC] ->
GSI 5 (level, low) -> IRQ 5
[17179598.788000] PCI: Setting latency timer of device 0000:00:07.5 to
64
[17179598.860000] Yenta: ISA IRQ mask 0x0808, PCI irq 9
[17179598.860000] Socket status: 30000068
[17179598.860000] ACPI: PCI Interrupt 0000:00:0a.1[B] -> Link [LNKB] ->
GSI 10 (level, low) -> IRQ 10
[17179598.860000] Yenta: CardBus bridge found at 0000:00:0a.1
[104d:80f6]
[17179598.860000] Yenta: Using CSCINT to route CSC interrupts to PCI
[17179598.860000] Yenta: Routing CardBus interrupts to PCI
[17179598.860000] Yenta TI: socket 0000:00:0a.1, mfunc 0x012c1222,
devctl 0x66
[17179598.940000] parport_pc: VIA parallel port: io=0x378, irq=7
[17179599.008000] Real Time Clock Driver v1.12
[17179599.092000] Yenta: ISA IRQ mask 0x0808, PCI irq 10
[17179599.092000] So...

Read more...

I forgot: I tried with the old /etc/pcmcia/config.opts, and booting with pci=assign-busses. No go.
Please?

Maybe noone is interested (I had no feedback). But if you look at here:

http://lists.infradead.org/pipermail/linux-pcmcia/2006-August/003893.html

I found a solution.
Get rid of .cis file and start manually cardmgr. The modem works.

Bye

Download full text (3.1 KiB)

The pcmcia subsystem fails to detect the modem part of a multifunction pcmcia
card (3com megahertz 3cxem556b net+modem). This card worked fine with pcmcia-cs,
and the problem appeared in FC5 and also in rawhide, with pcmciautils. I tested
this case with two laptops, a T60p with FC5 fully updated, and a T40 running
rawhide. This is what I obtain, when I insert the card (pccardctl eject ;
pccardctl insert), there's no trace of the modem function:

Sep 24 22:47:02 localhost kernel: pccard: PCMCIA card inserted into slot 0
Sep 24 22:47:02 localhost kernel: pcmcia: registering new device pcmcia0.0
Sep 24 22:47:02 localhost kernel: eth0: 3Com 3c589, io 0x300, irq 3, hw_addr
00:00:86:36:E0:9F
Sep 24 22:47:02 localhost kernel: 8K FIFO split 5:3 Rx:Tx, auto xcvr

I grabbed the cis file from the old pcmcia-cs package, and put it in
/lib/firmware/3CXEM556.cis to make udev helper functions happy.

I also recompiled cardmgr from the latest pcmcia-cs tarball, and went a bit
further, when launching cardmgr, the modem capabilities are detected by the
kernel, the serial_cs module is loaded, the /dev/modem is created:

pcmcia: Detected deprecated PCMCIA ioctl usage from process: cardmgr.
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.
pcmcia: registering new device pcmcia0.1
0.1: ttyS0 at I/O 0x3f8 (irq = 3) is a 16550A
eth0: interrupt(s) dropped!
2.6. kernels use pcmciamtd instead of memory_cs.c and do not require special
MTD handling any more.

The modem is detected, but doesn't respond to any at commands (same irq thatn
network ? conflict with pcmciautils ? maybe). But as pcmcia-cs is deprecated,
this is certainly not the way to solve this issue. Anyway, this demonstrates
that the modem function is available, and probably should work out-of-the-box
with kernel support+pcmciautils.

[root@bonobo pcmcia]# find /sys/bus/pcmcia/
/sys/bus/pcmcia/
/sys/bus/pcmcia/drivers
/sys/bus/pcmcia/drivers/3c589_cs
/sys/bus/pcmcia/drivers/3c589_cs/bind
/sys/bus/pcmcia/drivers/3c589_cs/unbind
/sys/bus/pcmcia/drivers/3c589_cs/module
/sys/bus/pcmcia/drivers/3c589_cs/0.0
/sys/bus/pcmcia/devices
/sys/bus/pcmcia/devices/0.0
[root@bonobo pcmcia]# find /sys/class/pcmcia_socket/
/sys/class/pcmcia_socket/
/sys/class/pcmcia_socket/pcmcia_socket0
/sys/class/pcmcia_socket/pcmcia_socket0/available_resources_mem
/sys/class/pcmcia_socket/pcmcia_socket0/available_resources_io
/sys/class/pcmcia_socket/pcmcia_socket0/cis
/sys/class/pcmcia_socket/pcmcia_socket0/available_resources_setup_done
/sys/class/pcmcia_socket/pcmcia_socket0/card_irq_mask
/sys/class/pcmcia_socket/pcmcia_socket0/card_eject
/sys/class/pcmcia_socket/pcmcia_socket0/card_pm_state
/sys/class/pcmcia_socket/pcmcia_socket0/card_insert
/sys/class/pcmcia_socket/pcmcia_socket0/card_vcc
/sys/class/pcmcia_socket/pcmcia_socket0/card_vpp
/sys/class/pcmcia_socket/pcmcia_socket0/card_voltage
/sys/class/pcmcia_socket/pcmcia_socket0/card_type
/sys/class/pcmcia_socket/pcmcia_socket0/device
/sys/class/pcmcia_socket/pcmcia_socket0/uevent

Any hint on how I can investigate further on this...

Read more...

I inserted some debug statements with jprobes in the pcmcia code, and I have a
better view of what certainly occurs: when powered up, the pcmcia card shows a
single function (network), so the 3c589_cs is loaded. Then the 3CXEM556.cis
firmware is loaded by the network driver, that overrides the cards buggy cis.
Now the cis tells that the card has multifunctions (network+modem), but it's too
late, because there's no pcmcia_bus_rescan() occuring after the new cis has been
loaded. Does it make sense ?

Created attachment 137504
linux-2.6.17-pcmcia-rescan-when-rewriting-cis.patch

The ret variable is not supposed to be zero here, because it is initialised to
the value of count (size of the cis file), and is only modified when
pcmcia_replace_cis() fails (-EIO). This patch forces a pcmcia_bus_rescan() when
writing a new cis file through the /sys/ interface.

Created attachment 137505
linux-2.6.17-pcmcia-delete-devices-after-cis-update.patch

When a new cis file is loaded, pcmcia_bus_rescan() is called, and nothing will
occur if the previous cis already provided a function that got registered.
This is the case with the megahertz 3CXEM556 B network/modem card : initially,
only the network function is advertized by the card.

Maybe we can assume that the previous registered information simply needs to be
dropped, before re-adding the card _from scratch_. This is what this patch
proposes.

It works for me : the modem function is correctly detected, I just need to
manually launch pcmcia-socket-startup, so pcmcia_bus_rescan() is called after
the new cis file has been loaded, triggered by the 3c589_cs module.

But : there's still an IRQ conflict between network and modem functions, that
cannot be used simultaneously. This is not really a problem, because a
workaround consists simply to disable the network device, and to autoconfigure
the serial port :

  # ifconfig eth0 down
  # setserial autoconfig auto_irq /dev/ttyS0

It seems a kernel bug. Look at:

http://lkml.org/lkml/2006/10/1/179

and at

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=207910

(is there anyone out there? :-))

Created attachment 140264
start over after CIS override

Many thanks for debugging this issue. The attached patch should address it in a
slightly different way; for only in the "replace CIS" codepath devices will be
removed and re-added.

It works for me (2.6.19-rc4-git7). The pre-required steps now to make the modem
function of my pcmcia card usable are :

  - prevents the network driver from being loaded (install 3c589_cs /bin/true in
modprobe.conf), else there's irq conflict between network and modem function
(see following log, "pcmcia: request for exclusive IRQ could not be fulfilled")

  - manually load the CIS file via sysfs (cat /lib/firmware/3CXEM556.cis >
/sys/class/pcmcia_socket/pcmcia_socket0/cis), altough the CIS has already been
loaded by the network driver from another code path (see following log too, "ds:
trying to load firmware 3CXEM556.cis").

I'm wondering if the setup process could be somewhat automatized via the generic
udev rules (does it make sense to blacklist this card in pcmcia-check-broken-cis
for example ?)

Created attachment 140463
log with 3cxem556-b multifunction card, kernel-2.6.19-rc4-git7 + dominik patch

Please see
https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.17/+bug/52510

It is fixed for me now! Thanks to all the people involved!

Hi,
just a comment (if anyone's listening) that Linus included the fix into 2.6.20-rc1 kernel (not released yet, but the relevant patches are into Linus' tree). It will be probably backported to 2.6.19.y.
What about backporting the fix into next kernel release? I can confirm that the abovementioned patches neatly apply to Ubuntu Edgy current kernel, compile and run fine.

Andover Schmeels (shattersword) wrote :

I second your backporting motion, though I'm sure that no one cares that I do. Tracking this problem down was a fricking nightmare =)

Now it works fine with kernel-2.6.20-1.2925.fc6

Thank you for your bug report. Do you still have this issue with the latest release of Ubuntu ?

Changed in linux-source-2.6.17:
status: Unconfirmed → Needs Info

I am not sure about it, because I am running Edgy --- I have a bit of fear
to upgrade, this quite an old machine and I am thru a period in which I need
it working 24x7... But:

1) I had an private mail interchange with a Feisty user with the same card;
it worked after I sent him the .cis file and instructed to put it in the
right place; I dug the file out of the old cardmgr package. I do not know
how to check if it is a Feisty or user problem;

2) I am now running a vanilla 2.6.21.2 and e card works, alhough it has
another problem with a 60 seconds delay in resume, see
http://lkml.org/lkml/2007/5/23/38 and related threads. But that's another
problem.

So, I think that _this_ bug can be closed as far as you can check that .cis
file is distributed correctly with Feisty.

Thanks!

Well, I have no idea about how i could check that, maybe you could try with a live cd if it works (ad if you have the time ) ? Thank you

Any news on this ?

Changed in linux-source-2.6.17:
importance: Undecided → Medium

Ok,

I managed (sorry for the delay, I run very short of time) to boot a 7.04 live CD. Out of the box the card does not function, because the necessary .cis file (3CXEM556.cis) is not in /lib/firmware. I copied this file from the old pcmcia package (they where in /etc/pcmcia/cis/ directory) and then all worked ok.

So: the good thing is that the Feisty kernel is ok. The bad ones is that somehow the .cis files that where in the obsolete pcmcia package, and that are needed, wheren't packaged in Feisty.

So now I do not know to whom pass the ball. I think that the .cis files should be added to the pcmciautils package, no? There is a possibility to "add" the pcmciautils package to this bug?

Launchpad Janitor (janitor) wrote :

[Expired for linux-source-2.6.17 (Ubuntu) because there has been no activity for 60 days.]

Changed in fedora:
importance: Unknown → Medium
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.