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 orinoco_cs. This is because anaconda stuck a "alias eth1 orinoco_cs" in my /etc/modprobe.conf. The current work around is the following: modprobe yenta_socket /etc/init.d/pcmcia restart
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
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 laptop. 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)
maybe its related to the mini pci card as i dont have one of those.
Dax, I have the same problem as well. I was thinking about just putting, modprobe yenta_socket in my rc.local file.
That qualifies as a workaround. I'm hoping for a clean fix.
Jermey. What kind of laptop do you have?
What does your /etc/sysconfig/pcmcia look like?
Mine which is working is PCMCIA=yes PCIC=yenta_socket PCIC_OPTS= CORE_OPTS=
Mine, which isn't working: [root@mentor root]# cat /etc/sysconfig/pcmcia PCMCIA=yes PCIC=yenta_socket PCIC_OPTS= CORE_OPTS= [root@mentor root]# lsmod | grep yenta [root@mentor root]#
I have a Dell Latitude C600
Same problem on ThinkPad 600E too.
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.
Basically, cardmgr doesn't activate the module if it doesn't load it itself? That sounds like a cardmgr bug.
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.
Created attachment 99910 [details] snippets from /var/log/messages
*** Bug 122355 has been marked as a duplicate of this bug. ***
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: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=120988 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=71602
Commenting out "alais eth1 orinoco_cs" from /etc/modprobe.conf solves this problem for me as well. And this was added there by anaconda.
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.
*** Bug 116205 has been marked as a duplicate of this bug. ***
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.
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 :-(
*This* is the blocker bug..
Created attachment 100150 [details] pcmcia-cs-load-PCIC-module.patch 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)
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 working. Imagine my surprise when the next boot did not start the network and cardmgr. 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 Controller 00:0c.1 CardBus bridge: Texas Instruments PCI4451 PC card Cardbus Controller 00:0c.2 FireWire (IEEE 1394): Texas Instruments PCI4451 IEEE-1394 Controller 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
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.
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)
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
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.
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.)
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.
*** Bug 123734 has been marked as a duplicate of this bug. ***
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)
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.
Re: point 2 of comment 34 Was that an attempt to upgrade via FTP, HTTP, or NFS?
*** Bug 122715 has been marked as a duplicate of this bug. ***
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 me.
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.
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 me. 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 /proc/devices. 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.
*** Bug 116367 has been marked as a duplicate of this bug. ***
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? -Will
*** Bug 127248 has been marked as a duplicate of this bug. ***
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.
I'm having the same problem on a Compaq Armada M700 laptop with a Cisco Systems Airo 340 PCMCIA wireless network card.
*** Bug 64090 has been marked as a duplicate of this bug. ***
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 use. 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. --TheHorse13
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 yenta_socket. 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.
*** Bug 109610 has been marked as a duplicate of this bug. ***
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.
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.
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.
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?
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.
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).
*** Bug 122740 has been marked as a duplicate of this bug. ***
*** Bug 126133 has been marked as a duplicate of this bug. ***
*** Bug 127811 has been marked as a duplicate of this bug. ***
*** Bug 124637 has been marked as a duplicate of this bug. ***
Please try pcmcia-cs-3.2.7-1.8.2.1 in FC2 test updates.
*** Bug 123266 has been marked as a duplicate of this bug. ***
*** Bug 122875 has been marked as a duplicate of this bug. ***
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.
*** Bug 132356 has been marked as a duplicate of this bug. ***
*** Bug 132394 has been marked as a duplicate of this bug. ***
*** Bug 132393 has been marked as a duplicate of this bug. ***
Pushing update final.