Red Hat Bugzilla – Bug 420
pcmcia and 3c574 difficulties
Last modified: 2008-05-01 11:37:48 EDT
I have a Compaq Armada 4220T and a 3Com 3c574 10/100 10baseT
PCMCIA network card. I have tried to connect to several
different 10baseT networks. Most of the time, the pcmcia
system picks up the card, loads the correct modules into the
kernel, starts inetd, and nothing works. I can ping the
interface from the host machine, but the packets end up on
the lo interface packet count. For absolutely no discerable
reason, with no changes to any configuration files, the same
normal bootup ends up with a successful network connection.
I have tried rebooting, kill -1ing the cardmgr, switching
slots, different networks, warm reboots, cold reboots, and
soft ifconfig/ifup/ifport resets. All in all, most of the
time I am prevented from connecting to any network and
getting work done. Love you, love RedHat Linux, help please.
It is hard to convince management Linux is good when I can't
give them the network server/system demos. :0
I have had the exact same problem. Unfortunately the 3COM-3C574TX is
considered UNSTABLE. three possible suggestions that were reported as
1. turn debug mode on... -DPCMCIA_DEBUG=1
2. execute /sbin/init.d/pcmcia restart
3. cardctl eject/cardctl insert
(I got these suggestions from hyper.stanford.edu, however I'm not sure
where the edits are supposed to be made or the distribution that it
As stated by the second user, the 3Com 574 is still considered
experimental and therefore we recommend using a network card that is
on the well-supported list.
This bug was fixed in pcmcia_cs 3.0.11. Upgrading to that would
remove this problem and make the 3c574 workable (if not ideal). Is
there any way this might be upgraded?
From the release notes:
The big news is that the most serious 3c574_cs bug has been fixed. I
finally got a code snippet from 3Com from their
driver initialization routine, and dropping it into 3c574_cs
immediately solved the problem where the card simply refused
to do anything. I also added some code to monitor the transceiver
status, and to also check for and sort-of recover
from missed interrupts. Performance on 100baseT still stinks.