Bug 121742 (fc2-pcmcia) - yenta_socket not loaded so PCMCIA broken
Summary: yenta_socket not loaded so PCMCIA broken
Alias: fc2-pcmcia
Product: Fedora
Classification: Fedora
Component: pcmcia-cs
Version: 2
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Dave Jones
QA Contact:
: 64090 109610 116205 116367 122355 122715 122740 122875 123266 123734 124637 126133 127248 127811 132356 132393 132394 (view as bug list)
Depends On:
Blocks: FC2Blocker FC3Target
TreeView+ depends on / blocked
Reported: 2004-04-27 07:09 UTC by Dax Kelson
Modified: 2015-01-04 22:05 UTC (History)
31 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2004-10-11 18:57:45 UTC

Attachments (Terms of Use)
snippets from /var/log/messages (2.69 KB, text/plain)
2004-05-03 13:09 UTC, Kevin Otte
no flags Details
pcmcia-cs-load-PCIC-module.patch (458 bytes, text/plain)
2004-05-11 14:41 UTC, Bastien Nocera
no flags Details
fix 2 bugs in /etc/init.d/pcmcia (736 bytes, patch)
2004-05-19 22:26 UTC, Gilbert E. Detillieux
no flags Details | Diff

Description Dax Kelson 2004-04-27 07:09:41 UTC
Description of problem:

On Fedora Core Test 1,2,3 installed on my Dell Inspiron 4150 the
kernel module yenta_socket isn't loaded and therefore my PCMCIA
devices including my builtin wireless NIC don't work.

All other required modules are loaded such as ds and pcmcia_core. The
drivers for my wireless card are loaded as well hermes,orinoco, and

This is because anaconda stuck a "alias eth1 orinoco_cs" in my

The current work around is the following:

modprobe yenta_socket
/etc/init.d/pcmcia restart

Comment 1 Dennis Gilmore 2004-04-27 11:02:59 UTC
I have a inspiron 4150 also and have not experienced this behaviour 
pcmcia works as expected when i plugin my wireless nic  it comes up. 
my /etc/modprobe.conf contains only  
alias eth0 3c59x 
alias sound-slot-0 snd-intel8x0 
install snd-intel8x0 /sbin/modprobe --ignore-install snd-intel8x0 
&& /usr/sbin/alsactl restore >/dev/null 2>&1 || : 
remove snd-intel8x0 { /usr/sbin/alsactl store >/dev/null 2>&1 
|| : ; }; /sbin/modprobe -r --ignore-remove snd-intel8x0 
alias usb-controller uhci-hcd 
this was from a clean install of test2  

Comment 2 Dax Kelson 2004-04-27 16:25:41 UTC
I've had RHL7.3, RHL8, RHL9, FC1 installed and used without troubles
(well, 7.3 was problematic for other reasons).

This problem of yenta_socket not be loaded is definitely real on my

Here is my wireless card details.

# cardctl ident
Socket 0:
  no product info available
Socket 1:
  no product info available
Socket 2:
  product info: "Dell", "TrueMobile 1150 Series PC Card", "Version
01.01", ""
  manfid: 0x0156, 0x0002
  function: 6 (network)

Comment 3 Dennis Gilmore 2004-04-27 21:51:39 UTC
maybe its related to the mini pci card as i dont have one of those. 

Comment 4 Jeremy Phillips 2004-04-28 02:59:27 UTC
Dax,  I have the same problem as well.  I was thinking about just
putting, modprobe yenta_socket in my rc.local file.

Comment 5 Dax Kelson 2004-04-28 03:17:49 UTC
That qualifies as a workaround. I'm hoping for a clean fix.

Comment 6 Dax Kelson 2004-04-28 03:35:19 UTC
Jermey. What kind of laptop do you have?

Comment 7 Bill Nottingham 2004-04-29 03:00:36 UTC
What does your /etc/sysconfig/pcmcia look like?

Comment 8 Dennis Gilmore 2004-04-29 03:04:33 UTC
Mine which is working is  

Comment 9 Dax Kelson 2004-04-29 03:12:14 UTC
Mine, which isn't working:

[root@mentor root]# cat /etc/sysconfig/pcmcia
[root@mentor root]# lsmod | grep yenta
[root@mentor root]#

Comment 10 Jeremy Phillips 2004-04-29 08:44:16 UTC
I have a Dell Latitude C600

Comment 11 Mikko Paananen 2004-04-29 23:37:14 UTC
Same problem on ThinkPad 600E too.

Comment 12 Kevin Otte 2004-05-02 18:15:18 UTC
Seeing this on an eMachines M5305 with a Cisco Aironet 340 card.

Removing the "alias eth1 airo_cs" from /etc/modprobe.conf allowed the
PCMICA subsystem to start properly and activate the Aironet card.

It looks like the installer needs some way of not adding PCMCIA cards
to the modprobe.conf so cardmgr can activate the socket and thus the
cards at the proper time.

Comment 13 Bill Nottingham 2004-05-03 00:49:07 UTC
Basically, cardmgr doesn't activate the module if it doesn't load it
itself? That sounds like a cardmgr bug.

Comment 14 Kevin Otte 2004-05-03 13:09:19 UTC
After reading my own comment I realize I was a bit unclear.

With the "alias eth1 airo_cs" line in /etc/modprobe.conf, yenta_socket
itself is not being loaded by whatever script is supposed to load it.

From the looks of it, by loading a *_cs module as part of the
networking startup, you tie up the socket in such a way that
yenta_socket cannot load as part of the pcmcia startup.

Attachment forthcoming.

Comment 15 Kevin Otte 2004-05-03 13:10:00 UTC
Created attachment 99910 [details]
snippets from /var/log/messages

Comment 16 Bill Nottingham 2004-05-04 22:13:53 UTC
*** Bug 122355 has been marked as a duplicate of this bug. ***

Comment 17 Dax Kelson 2004-05-04 22:35:49 UTC
I can confirm that removing the line "alias eth1 orinoco_cs" from my
/etc/modprobe.conf fixes the problem.

Should it work anyway?

BTW, anaconda put that line in the file.

I suspect that the following bugs are related:


Comment 18 Colin Charles 2004-05-06 05:53:50 UTC
Commenting out "alais eth1 orinoco_cs" from /etc/modprobe.conf solves
this problem for me as well. And this was added there by anaconda.

Comment 19 Pete Sridharan 2004-05-08 12:52:35 UTC
I just upgraded my Thinkpad T22 to Fedeora Core 2 Test 3 and had the 
same problem with the Linksys Wireless v3.
After I removed the alias eth1 orinoco_cs from my /etc/modprobe.conf 
on my Thinkpad T22, the cardctl was still trying to load the 
prism2_cs card from the wlan_ng package and failing.
 But after uninstalling the wlan_ng package, the orinoco drivers come 
up fine. 
 Thanks for all those in this thread who helped to indentify the 
issue in the modprobe.conf.

Comment 20 Tim Waugh 2004-05-10 14:07:02 UTC
*** Bug 116205 has been marked as a duplicate of this bug. ***

Comment 21 Tim Waugh 2004-05-10 14:23:02 UTC
Removing the eth alias doesn't work for me (there is only one
interface anyway).  I need the hack from bug #116205 - to make the
pcmcia init script load $PCIC regardless of whether pcmcia is listed
in /proc/devices - in order to get PCMCIA working.

Comment 22 Alexandre Oliva 2004-05-10 15:02:27 UTC
Why was the older bug containing a patch that fixes (or at least works
around) the problem marked as a dup of this one? (namely bug 116205) 
This is a sure way to lose track of the patch :-(

Comment 23 Tim Waugh 2004-05-10 15:03:22 UTC
*This* is the blocker bug..

Comment 24 Bastien Nocera 2004-05-11 14:41:48 UTC
Created attachment 100150 [details]

Here the $PCIC module (most of the time yenta_socket) will be loaded even if
/proc/devices contains the "pcmcia" string, and if $PCIC isn't already loaded.

This still breaks on some machines (like mine) where it seems that the pcmcia
socket driver needs to be loaded before any drivers depending on it. But it's
been tested on some other machines where the problem didn't occur.

(This is a similar patch to that was marked as merged in #112459)

Comment 25 cam 2004-05-16 11:19:45 UTC
Another data point, I discovered this bug on my machine. I did a clean
install of FC2 test3 from isos and on the first boot the machine was

Imagine my surprise when the next boot did not start the network and

I found a workaround above - to manually modprobe yenta_socket and
service pcmcia restart, also works for me. 

I will now remove alias eth1 orinoco_cs from modprobe.conf

Related info: notebook Sharp PC AR-50
# /sbin/lspci
00:00.0 Host bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX Host
bridge (rev 03)
00:01.0 PCI bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge
(rev 03)
00:07.0 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ISA (rev 02)
00:07.1 IDE interface: Intel Corp. 82371AB/EB/MB PIIX4 IDE (rev 01)
00:07.2 USB Controller: Intel Corp. 82371AB/EB/MB PIIX4 USB (rev 01)
00:07.3 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ACPI (rev 03)
00:0b.0 Ethernet controller: Accton Technology Corporation EN-1216
Ethernet Adapter (rev 11)
00:0c.0 CardBus bridge: Texas Instruments PCI4451 PC card Cardbus
00:0c.1 CardBus bridge: Texas Instruments PCI4451 PC card Cardbus
00:0c.2 FireWire (IEEE 1394): Texas Instruments PCI4451 IEEE-1394
00:0e.0 Multimedia audio controller: ESS Technology ES1988 Allegro-1
(rev 12)
00:0e.1 Communication controller: ESS Technology ESS Modem (rev 12)
01:00.0 VGA compatible controller: ATI Technologies Inc Rage Mobility
P/M AGP 2x (rev 64)

# cardctl ident
Socket 0:
  product info: "Belkin", "11Mbps Wireless Notebook Network Adapter",
"Version 01.02", ""
  manfid: 0x0156, 0x0002
  function: 6 (network)
Socket 1:
  no product info available

Comment 26 Gilbert E. Detillieux 2004-05-19 22:26:27 UTC
Created attachment 100359 [details]
fix 2 bugs in /etc/init.d/pcmcia

A possibly cleaner test for PCIC module,
plus a bug fix in test for "ds" module, which prevented rmmod's from happening.

Comment 27 cam 2004-05-21 11:03:59 UTC
FYI this did not happen when I installed FC2 final (not test),
although there were still some problems with the detection / config of
the wireless pcmcia card (123715, 123733, 123738)

Comment 28 Michael 2004-05-22 10:11:03 UTC
FC2 Test 3 on Dell Inspiron 7500
Same problem. 
commenting out orinoco_cs in /etc/modprobe.conf works
so does pcmcia init script hack in bug #116205 

Comment 29 Chris Colohan 2004-05-22 20:57:04 UTC
FYI, this bug still existed when I installed FC2 final (not test) on
my Dell Inspiron 4000.  The workaround posted in bug #116205 resolved
it for me, but it is not a clean solution.

I am curious -- what is the impact of this bug?  Is yenta_socket used
by all PCMCIA configurations, or just ones with a particular chipset?
 I know that many of my colleagues at CMU are holding off on touching
FC2 until this issue is resolved, since many folks use PCMCIA wireless
cards as their sole network connection.

Comment 30 Barry K. Nathan 2004-05-22 22:15:29 UTC
Modern laptops (and I guess many no-longer-modern ones too) have
CardBus slots. The vast majority of CardBus controllers are driven by
the yenta_socket driver. If a laptop uses a driver other than CardBus,
chances are it's because it has a plain PCMCIA slot that does not have
CardBus support. (It's been many years since I've seen those. I think
they may still be used on some 802.11b cards for desktop computers,
but I'm really not sure about that.)

Comment 31 Eric Herman 2004-05-25 02:12:15 UTC
KDS 671XH also has this problem with the Yenta Socket. It worked
nicely under FC1. However, FC2 produced the exact same error.
Commenting out /etc/modprob.conf made it boot correctly.

HOWEVER, it broke the loading of S25netfs which caused my NFS mounts
to not work. I "mv S24pcmcia S11pcmcia" in directory /etc/rc.d/rc5.d.
By causing PCMCIA to load earlier, it seems to be OK now.

Comment 32 Bill Nottingham 2004-05-25 16:12:53 UTC
*** Bug 123734 has been marked as a duplicate of this bug. ***

Comment 33 David Eisner 2004-05-26 04:41:05 UTC
Same problem with Dell Inspiron 5000e running FC2 final.  Worked fine
with FC1.  I've had the same results as most others here: the 
"modprobe yenta_socket; /etc/init.d/pcmcia restart" trick
works, and commenting out "alias eth0 orinoco_cs" provides a 
permanet workaround.

[root@arcadia /]# /sbin/cardctl ident
Socket 0:
  product info: "Lucent Technologies", "WaveLAN/IEEE", "Version 01.01", ""
  manfid: 0x0156, 0x0002
  function: 6 (network)
Socket 1:
  no product info available
[root@arcadia /]# /sbin/lspci
00:00.0 Host bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX Host
bridge (rev 03)
00:01.0 PCI bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge
(rev 03)
00:04.0 CardBus bridge: Texas Instruments PCI1225 (rev 01)
00:04.1 CardBus bridge: Texas Instruments PCI1225 (rev 01)
00:07.0 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ISA (rev 02)
00:07.1 IDE interface: Intel Corp. 82371AB/EB/MB PIIX4 IDE (rev 01)
00:07.2 USB Controller: Intel Corp. 82371AB/EB/MB PIIX4 USB (rev 01)
00:07.3 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ACPI (rev 03)
00:08.0 Multimedia audio controller: ESS Technology ES1978 Maestro 2E
(rev 10)
01:00.0 VGA compatible controller: ATI Technologies Inc Rage Mobility
M3 AGP 2x (rev 02)

Comment 34 Charles Curley 2004-05-27 14:25:52 UTC
1) I can confirm this bug for a Toshiba Tecra 8000 in FC2 Final with a
   Netgear FA411 Ethernet card.

   "modprobe yenta_socket" followed by "service pcmcia start" got the
   network running.

   [root@teckla init.d]# cardctl ident
   Socket 0:
     no product info available
   Socket 1:
     product info: "NETGEAR", "FA411", "Fast Ethernet"
     manfid: 0x0149, 0x0411
     function: 6 (network)

   [root@teckla init.d]# lspci
   00:00.0 Host bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX Host
bridge (AGP disabled) (rev 02)
   00:04.0 VGA compatible controller: Neomagic Corporation NM2200
[MagicGraph 256AV] (rev 20)
   00:05.0 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ISA (rev 02)
   00:05.1 IDE interface: Intel Corp. 82371AB/EB/MB PIIX4 IDE (rev 01)
   00:05.2 USB Controller: Intel Corp. 82371AB/EB/MB PIIX4 USB (rev 01)
   00:05.3 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ACPI (rev 02)
   00:09.0 Communication controller: Toshiba America Info Systems FIR
Port (rev 23)
   00:0b.0 CardBus bridge: Toshiba America Info Systems ToPIC97 (rev 05)
   00:0b.1 CardBus bridge: Toshiba America Info Systems ToPIC97 (rev 05)

2) While trying to upgrade the Tecra, I was unable to use the network
   under Anaconda. The first time I tried, I had the network, but very
   slowly and very unreliably. I rebooted, and had no network
   (including no lights on the Ethernet card). I completed the upgrade
   using CD-RWs. I have neither filed nor checked for an Anaconda bug.

3) Tim Waugh's fix on 2004-03-18 11:16 in bug 116205
   (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=116205) seems
   to solve the problem.

4) I have not removed the eth0 line from /etc/modprobe.conf. My
   computer boots with that line present.

5) Thank you all very much for all the work.

Comment 35 Barry K. Nathan 2004-05-27 15:44:49 UTC
Re: point 2 of comment 34

Was that an attempt to upgrade via FTP, HTTP, or NFS?

Comment 36 Bill Nottingham 2004-05-27 19:23:07 UTC
*** Bug 122715 has been marked as a duplicate of this bug. ***

Comment 37 Brian Kendig 2004-05-30 00:42:29 UTC
I also hit this problem in FC2 final release on my Dell Latitude CPi D266XT laptop with a 
3Com PCMCIA ethernet card. Tim Waugh's solution, linked above, solved the problem for 

Comment 38 Fred Bacon 2004-06-02 16:29:59 UTC
At least in my experience, the solution seems to be to change the
order in which the pcmcia subsystem is started in the boot process. 
Currently in FC2, the pcmcia starts has a chkconfig setting of 2345 25
96.  If you change this to 2345 08 96, then everything starts up fine.

Comment 39 Ian Collier 2004-06-10 11:59:37 UTC
I confirm this bug, but in my case the bug is actually in `neat'.
Pretty much all of what I'm about to say has already been covered
in the earlier comments.

System: ThinkPad T22 with 3Com OfficeConnect wireless ethernet card
under Fedora Core 2 release.

What happened: installation was fine; I told it not to configure eth0
(the built-in ethernet port) but it also didn't configure the wireless
ethernet card.

After boot, I ran `neat' to set up the wireless connection.  This forced
me to choose from a list of hardware that didn't contain my card, so
I arbitrarily chose "3c589 PCMCIA card".  As a result, the line
"alias eth1 3c589_cs" was placed in my modprobe.conf file, unknown to

At next boot the PCMCIA subsystem failed to initialise properly. The
reason for this was the network subsystem loaded 3c589_cs along with
*half* the required PCMCIA modules; the PCMCIA subsystem doesn't
bother to load the (rest of the) modules if it detects pcmcia in 

Solution: remove the line from modprobe.conf, and all is working again.

Proposed fix: `neat' (or `anaconda') should not place modules for PCMCIA
cards in the modprobe.conf file.  It works perfectly well without them.

Comment 40 Dave Jones 2004-06-18 18:59:22 UTC
*** Bug 116367 has been marked as a duplicate of this bug. ***

Comment 41 Will Lucas 2004-06-23 12:13:36 UTC
yeah i had the same problem with my Dell Inspiron 8200. however i 
fixed the problem a little bit differently.

>$ cd /etc/rc5.d
>$ mv S10network S24network
>$ mv S24pcmcia S10pcmcia

this way pcmcia starts up before network and there are no errors 
about can't find orinoco_cs. also now the yenta_socket loads just 
fine as well. i'm not sure but there must have been something that 
was interfering with the pcmcia loading into /proc/devices when it 
wasn't being loaded before network. also i was wondering why would 
one put the network script before the pcmcia, when there might be a 
networking device in pcmcia?


Comment 42 Bill Nottingham 2004-07-06 21:20:21 UTC
*** Bug 127248 has been marked as a duplicate of this bug. ***

Comment 43 Alan Crosswell 2004-07-07 19:28:39 UTC
This seems like it might be yet another case of kudzu touching stuff.
 I've commented out eth0 and disabled kudzu to get this working on a
Thinkpad 600X.

Comment 44 Uwe Kubosch 2004-07-30 11:11:22 UTC
I'm having the same problem on a Compaq Armada M700 laptop with a
Cisco Systems Airo 340 PCMCIA wireless network card.

Comment 45 Bill Nottingham 2004-08-03 03:01:51 UTC
*** Bug 64090 has been marked as a duplicate of this bug. ***

Comment 46 Sonny Discini 2004-08-04 19:38:21 UTC
Yes, my Thinkpad 600E has the same issue. While the work-around 
posted does work, it only works for the current session. I found a 
perminant. Start pcmcia *before* network in each runlevel that you 

e.g. go into etc/rc.d/rc3.d and rename the startup script to an 
available number that is lower than network. If network is 
S10network, use S09pcmcia if S09 is available. 

This works without fail on my Thinkpad 600E.


Comment 47 Miloš Komarčević 2004-08-05 16:16:56 UTC
I've hit the same problem on my IBM TP600E after I added a 3Com
OfficeConnect wireless card which uses the atmel_cs module. I had a
working 3Com ethernet card in before that loads 3c59x, so I guess
without the *_cs in the module name there was no problems loading

I ask RH devs yet again, and I see many people also have for years
without answer, in numerous related bugs here (e.g. bug 116205, bug
105591): WHY is the pcmcia service not loaded early (before any
network stuff) by default, like it is in most other distributions?
AFAIK nothing should break?

This would kill bigger flies with one stone as well and stop the bad
practice of endless patching a problem that's really more elegantly
solved somewhere else.

Comment 48 Bill Nottingham 2004-08-27 22:41:40 UTC
*** Bug 109610 has been marked as a duplicate of this bug. ***

Comment 49 David Koconis 2004-08-31 14:19:37 UTC
I think this problem is related to the use of the "grep -q" command in
the /etc/init.d/pcmcia start-up script.  The man pages indicate that
grep should "Exit immediately with  zero status if any match is
found".  The pcmcia script tries to test for this with the line

if ! grep -q pcmcia /proc/devices ; then

In the above, even if the string pcmcia exists in /proc/devices
(meaning grep should exit with zero status), the bash shell does not
interpret "! (exit status zero)" as true, so the commands in the "if"
block are skipped (and the appropriate modules are not loaded).  I
fixed this problem by replacing the above line with two separate lines:

/bin/grep -q pcmcia /proc/devices 2>&1 > /dev/null
if [ "$?" == "0" ] ; then

This explicitly compares the exit status with zero.  Bash is happy and
the modules get loaded.

Comment 50 Tim Waugh 2004-08-31 14:28:41 UTC
I think you're missing the point of that bit of the script.  In plain
English it's trying to say this:

If pcmcia is not loaded, then
  load it

Your re-statement has completely inverted the meaning of the test, and
is equivalent to:

if grep -q pcmcia /proc/devices; then

And this, in turn, is equivalent to saying "if pcmcia is loaded then
load it".

What is incorrect is not the shell grammar, but the meaning associated
with the string 'pcmcia' being present in /proc/devices.

For whatever reason, 'pcmcia' already appears in /proc/devices even
when $PCIC still needs to be loaded.

Comment 51 David Koconis 2004-08-31 17:40:16 UTC
I see.  I misunderstood what it means to have the "pcmcia" present in
/proc/devices.  I thought it meant that some pcmcia devices were
present so relevant modules needed to be loaded.  You indicate that it
is supposed to mean $PCIC modules have already been loaded so you
don't need to try to load them again.

While I guess I did miss the point, my inversion of the meaning was
intentional.  I guess I was lucky that my "workaround" gets things
loaded and working on all the laptops around here.  Thanks for clueing
me in.

Comment 52 Alexandre Oliva 2004-08-31 17:41:45 UTC
One of the problems is that sometimes pcmcia is in /proc/devices
because *some* of the drivers are loaded, but not all of them.  This
was the problem I've had since early FC2.  Since it doesn't actually
run to try to probe for modules that are already loaded, so why not
just do it?

Comment 53 Bastien Nocera 2004-09-02 17:49:01 UTC
Alexandre, the main problem is that most PCMCIA drivers will not work
if they are loaded before the socket driver.
For example, try to boot without a network, modprobe your pcmcia
network driver, then the yenta_socket. Check dmesg, didn't do anything.
Now remove all those, and try to load the socket driver first, then
the network card driver, and it should work.

Comment 54 Alexandre Oliva 2004-09-03 18:18:22 UTC
Yup.  This might very well be the reason for the regression in bug
100528, with the new early loading of modules in /etc/rc.d/rc.sysinit
(the Initializing hardware... thingie).

Comment 55 Bill Nottingham 2004-09-07 18:28:29 UTC
*** Bug 122740 has been marked as a duplicate of this bug. ***

Comment 56 Bill Nottingham 2004-09-07 18:30:03 UTC
*** Bug 126133 has been marked as a duplicate of this bug. ***

Comment 57 Bill Nottingham 2004-09-07 18:32:53 UTC
*** Bug 127811 has been marked as a duplicate of this bug. ***

Comment 58 Bill Nottingham 2004-09-07 18:34:20 UTC
*** Bug 124637 has been marked as a duplicate of this bug. ***

Comment 59 Bill Nottingham 2004-09-08 06:11:51 UTC
Please try pcmcia-cs-3.2.7- in FC2 test updates.

Comment 60 Bill Nottingham 2004-09-08 06:57:34 UTC
*** Bug 123266 has been marked as a duplicate of this bug. ***

Comment 61 Bill Nottingham 2004-09-08 06:57:52 UTC
*** Bug 122875 has been marked as a duplicate of this bug. ***

Comment 62 Alexandre Oliva 2004-09-10 06:26:00 UTC
Seems to work for me.  Even without the work around patch I had in
place :-), that appears to be equivalent to the change that went in. 
Tested on FC3-re0908.0; I see FC2 is essentially equivalent as far as
/etc/init.d/pcmcia goes, so I'm not actually going through the trouble
of testing it there myself.

Comment 63 Bill Nottingham 2004-09-13 16:24:47 UTC
*** Bug 132356 has been marked as a duplicate of this bug. ***

Comment 64 Bill Nottingham 2004-09-13 17:35:01 UTC
*** Bug 132394 has been marked as a duplicate of this bug. ***

Comment 65 Bill Nottingham 2004-09-13 17:35:22 UTC
*** Bug 132393 has been marked as a duplicate of this bug. ***

Comment 66 Bill Nottingham 2004-10-11 18:57:45 UTC
Pushing update final.

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