Description of problem: My PCMCIA cards are not recognized or enabled Version-Release number of selected component (if applicable): pcmcia-cs-3.2.7-1.3 How reproducible: Every time Steps to Reproduce: 1. Boot system 2. Insert PCMCIA card 3. Actual results: The card is not recognized or enabled Expected results: The 3com 3C3FEM556C ethernet/modem card should be recognized and enabled. Additional info: 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 problem. 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 be fixed.
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 post later.
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 PC=/lib/modules/preferred/pcmcia else @@ -113,6 +113,7 @@ echo "module directory $PC not found." break fi + sleep 5 fi if [ -s /var/run/cardmgr.pid ] && \ @@ -127,6 +128,7 @@ echo "done." touch /var/lock/subsys/pcmcia 2>/dev/null + sleep 5 EXITCODE=0 ;;
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 unnecessarily.
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.