Red Hat Bugzilla – Bug 116205
PCMCIA devices not working in FC2 test 1
Last modified: 2007-11-30 17:10:36 EST
Description of problem:
My PCMCIA cards are not recognized or enabled
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Boot system
2. Insert PCMCIA card
The card is not recognized or enabled
The 3com 3C3FEM556C ethernet/modem card should be recognized and
I've tried other PCMCIA cards and none of them seem to work.
I performed a dump_cis and got:
open(): No such device
Is the pcmcia service running?
The service won't start (Anaconda did not configure it to start
automatically BTW) unless I do a "modprobe yenta_socket" first. That
actually got things working. I guess this is some sort of a module
loading problem then, yes?
Yup. There are several problems here, some of which I've mentioned in
bug 116666, but the patch is not enough, or even necessary, to fix the
The main remaining problem is that /etc/init.d/pcmcia uses grep -q
pcmcia /proc/devices to tell whether it has to load the socket
controller module, but it turns out that, because of dependencies of
pcmcia network controller modules that network start attempts to bring
up, pcmcia_core is brought in, adding pcmcia to /proc/devices. So the
test fails, and we fail to bring up $PCIC.
But even if the test didn't fail, /sbin/modprobe pcmcia_core would
fail, because of bug 116656, so the code has to be reworked to not
attempt to load a module that is already loaded, if 116656 is not to
With bug 116656 out of the way, turning the grep -q pcmcia
/proc/devices test in /etc/init.d/pcmcia into : got a 3c574_cs network
interface to be brought up correctly at boot time. I can post a patch
if it would make it any easiner for you, but I suppose the description
is simpler. If not, just let me know.
Nah, Test 1 proved too unstable for my purposes so I had to revert to
Red Hat 9. Why not just put it into the queue for Test 2?
Hmm... There seems to be a race condition in there somewhere. I have
actually verified that replacing the grep /proc/devices condition with
true fixed the problem yesterday, but later yesterday (after
installing all of yesterday's rawhide updates) and today, the network
card wouldn't be brought up even though the patch was there. I
noticed cardmgr would say it was only watching one socket at start up,
and apparently the network card was inserted in the other socket. The
reliable solution I found was to re-run mkinitrd --with=yenta_socket,
and then boot with acpi=off. With ACPI=on, the network interface
wouldn't be brought up, and the system boot up would stop while
starting cups, and never complete. Reverting to the original initrd,
and applying the pcmcia patch I suggested, yenta_socket would cause a
kernel oops (2.6.3-1.100). I have pictures of the stack trace, will
Actually, it wasn't an oops. It was just the kernel reporting, with a
stack trace, that nobody cared about the IRQ that the broken ACPI
tables of this Toshiba Tecra 8100 assigned to it (or so I'm told in
bug 100528). I'll add the information there. A sad bit is that
loading yenta_socket in initrd actually gets the network interface up,
but when X starts, the network card stops working. It no longer hangs
the system like back in bug 100920, but I have to remove and reinsert
the card for it to work again.
I found it sufficient to make these changes:
--- /etc/init.d/pcmcia.orig 2004-03-18 16:21:19.000000000 +0000
+++ /etc/init.d/pcmcia 2004-03-18 16:21:19.000000000 +0000
@@ -91,7 +91,7 @@
if [ ! -f $SC ] ; then umask 022 ; touch $SC ; fi
if [ "$SCHEME" ] ; then umask 022 ; echo $SCHEME > $SC ; fi
- if ! grep -q pcmcia /proc/devices ; then
+ if true ; then
if [ -d /lib/modules/preferred ] ; then
@@ -113,6 +113,7 @@
echo "module directory $PC not found."
+ sleep 5
if [ -s /var/run/cardmgr.pid ] && \
@@ -127,6 +128,7 @@
touch /var/lock/subsys/pcmcia 2>/dev/null
+ sleep 5
Awesome. I've tested the patch and confirmed that it is enough to get
all of the problems fixed. Apparently the kernel acpi work arounds
are now in. Cool! Thanks,
Is there a reason why pcmcia cannot be made to start up BEFORE the
network tries to start up? This would also eliminate a rather minor
but annoying problem in which the failed attempt to start up my
wireless card causes a FAILED message and bumps rhgb into verbose mode
It's not a good idea to place to unrelated issues in a single
bugzilla. Anyhow, yours is bug 105591.
*** This bug has been marked as a duplicate of 121742 ***
This patch fixed my pcmcia problem on an IBM Thinkpad A21p which began
after loading Fedora Core 2. So, it wasn't fixed in Core 2.
I just upgraded my Dell Inspiron 5100 to Fedora Core 2 and I also see
this problem. Thanks for the hint about "modprobe yenta_socket";
if I load that module I can start pcmcia and then my wireless card
works correctly. I suppose I could live with this workaround but it
will cause hassles for a lot of people, I fear.
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.