Bug 116205 - PCMCIA devices not working in FC2 test 1
Summary: PCMCIA devices not working in FC2 test 1
Keywords:
Status: CLOSED DUPLICATE of bug 121742
Alias: None
Product: Fedora
Classification: Fedora
Component: pcmcia-cs
Version: rawhide
Hardware: i686
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Arjan van de Ven
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-02-19 00:39 UTC by Michael St. Laurent
Modified: 2007-11-30 22:10 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-02-21 19:01:25 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Michael St. Laurent 2004-02-19 00:39:09 UTC
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

Comment 1 Bill Nottingham 2004-02-19 05:26:30 UTC
Is the pcmcia service running?

Comment 2 Michael St. Laurent 2004-02-19 17:16:11 UTC
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?

Comment 3 Alexandre Oliva 2004-02-24 09:32:26 UTC
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.

Comment 4 Alexandre Oliva 2004-02-24 21:27:21 UTC
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.

Comment 5 Michael St. Laurent 2004-02-24 21:30:11 UTC
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?

Comment 6 Alexandre Oliva 2004-02-25 13:07:36 UTC
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.

Comment 7 Alexandre Oliva 2004-02-26 03:40:06 UTC
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.

Comment 8 Tim Waugh 2004-03-18 16:16:47 UTC
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
        ;;
  


Comment 9 Alexandre Oliva 2004-03-19 16:24:42 UTC
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,

Comment 10 Joshua M. Thompson 2004-04-02 17:45:08 UTC
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.


Comment 11 Alexandre Oliva 2004-04-02 20:16:53 UTC
It's not a good idea to place to unrelated issues in a single
bugzilla.  Anyhow, yours is bug 105591.

Comment 12 Tim Waugh 2004-05-10 14:06:56 UTC

*** This bug has been marked as a duplicate of 121742 ***

Comment 13 Need Real Name 2004-07-21 17:08:08 UTC
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.

Comment 14 Joe Buck 2004-09-24 04:19:52 UTC
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.


Comment 15 Red Hat Bugzilla 2006-02-21 19:01:25 UTC
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.


Note You need to log in before you can comment on or make changes to this bug.