Red Hat Bugzilla – Bug 123457
FC2 Final yenta_socket not loaded so PCMCIA broken
Last modified: 2015-01-04 17:06:01 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 Description of problem: When I try to load the module orinoco_cs it complains about an unknown symbol in the module or unknown parameter. Further investigation says 'irq' is an unknown parameter. The card worked perfectly in FC1 using the same module. Version-Release number of selected component (if applicable): kernel-2.6.5-1.358 How reproducible: Always Steps to Reproduce: 1. Install FC2 2. Try to bring up Wireless connection Actual Results: "orinoco_cs device eth1 does not seem to be present, delaying initialization" at first, but now I can't even get the module to load. Expected Results: Working WiFi-network Additional info: System: Dell Inspiron 8200 Card: Dell Truemobile 1150 (orinoco_cs should work) When I first booted FC2 after a clean install, I got an error during startup ( orinoco_cs device eth1 does not seem to be present, delaying initialization ), so I went into system-config-network and removed it from the list to try to reconfigure it, but I can't find my card in the list (should the list of Wireless and Ethernet-cards really be the same, or is this another bug? I can't find my card or any compliant card (which uses the same orinoco_cs-module) on the list).. Running modprobe with -v gives me: [root@mobile root]# modprobe -v orinoco_cs insmod /lib/modules/2.6.5-1.358/kernel/drivers/net/wireless/orinoco_cs.ko irq=10 FATAL: Error inserting orinoco_cs (/lib/modules/2.6.5-1.358/kernel/drivers/net/wireless/orinoco_cs.ko): Unknown symbol in module, or unknown parameter (see dmesg) In /var/log/messages I find "May 18 21:25:30 mobile kernel: orinoco_cs: Unknown parameter `irq'"
Created attachment 100310 [details] Contents of dmesg during boot
This happens if I try to insmod it by hand: [root@mobile root]# insmod /lib/modules/2.6.5-1.358/kernel/drivers/net/wireless/orinoco_cs.ko [root@mobile root]# lsmod | grep orinoco orinoco_cs 6152 0 orinoco 31500 1 orinoco_cs hermes 6528 2 orinoco_cs,orinoco ds 12292 7 orinoco_cs pcmcia_core 46792 3 orinoco_cs,ds,yenta_socket It looks ok to me, but the card doesn't show when I issue "ifconfig -a"
I have this problem too, Dell Inspiron 7500, FC2. 'cardctl status' says open_sock(): No such device If I type 'modprobe yenta_socket' then 'cardctl status' says good things about my wireless card. After that, if I type 'service pcmcia start' then 'ifconfig eth0' says good things about eth0 being up and having an ip address (after dhcp has done its work). I'm hoping for an automatic solution, though.
Aha... I found the problem. In /etc/rc.d/init.d/pcmcia, there is a section that says 'if the string pcmcia isn't found in /proc/devices, modprobe $PCIC'. For some strange reason, 'pcmcia' is in /proc/devices before it gets to this stage. The right test would probably be to see if 'cardctl status' works or not. If not, then modprobe $PCIC.
And for the final coup-de-grace, getting the boot process to print no errors (like orinoco_cs not found, delaying initialization): Edit /etc/sysconfig/network-scripts/ifcfg-eth0 and set 'ONBOOT=no'. Eth0 still comes up when pcmcia comes up, a little later. The line I changed in /etc/rc.d/init.d/pcmcia is 95: #if ! grep -q pcmcia /proc/devices ; then if ! cardctl status 2>&1 > /dev/null ; then Enjoy!
*** Bug 123713 has been marked as a duplicate of this bug. ***
*** Bug 125015 has been marked as a duplicate of this bug. ***
Hey everybody. I'm a pretty inexperienced user, and I was delighted to find the fix proposed in comment #3. However, the automatic solution given in comment #5 simply didn't work for me. I edited both files, and while there was no error message the next time I booted, the internet didn't work. running "ifconfig" only showed me the loopback interface.. no eth0 I don't want to have to type in the series of commands above everyday. What's the best solution? Also, since it seems that this problem will prevent quite a lot of people from using the internet on their laptops (those with pcmcia network cards), isn't this a rather serious bug? Thanks for the help!
I found yesterday that if I completely delete both the Ethernet and Hardware definition for the PCMCIA NIC from the "Network Configuration" screens provided in Fedora / Redhat, then reboot, the card is not visible in the screens but is visible in ifconfi and the card SEEMS to work correctly at the moment. Note I have made the change to the config file described earlier so that may also be necessary. I agree completely this problem needs a permanent fix to be fitted back into the appropriate component. Who does that , I don't know. Clive
*** Bug 126172 has been marked as a duplicate of this bug. ***
I have chkconfig-ed pcmcia to off, so it won't start automatically. However, for some reason, after the system is completely booted up, there are a bunch of modules (orinoco_cs, orinoco, hermes, ds, pcmcia) already loaded into the kernel. This is why cat /proc/devices already contains a pcmcia line, which then in turn prevents /etc/init.d/pcmcia start from loading yenta_socket.
On a Toshiba 4300 Series laptop I have the same problem. I currently let the system boot normally with the errors, then use the following commands "service network stop", "service pcmcia stop", "modprobe yenta_socket", "service pcmcia start", "service network start" in a shell scrip to start my network. I'm going to put the commands in the /etc/rc.d/rc.local file so they will automatically run at start time. This should be a temporary fix until the /etc/init.d/pcmcia file is fixed. Does anybody else have a better suggestion for automating this until it's fixed ?
Some time ago I found a fix for this As I suspected, the problem on some laptop machines is the network is attempted to be started BEFORE pcmcia support No unfortunately I can't find the posting that explained the fix but it is somthing along the lines of the following ... Look in directory /etc/rc.d/rc5.d where 5 is the "run-level" for the "environment" you are running in. I think 5 is used for X-systems Now there will be entries named Knn and Snn where nn are integers between 0 and 9 I think the rule is some process at start of the run-level reads the rcx.d directory and starts all the applications via these parameter files or "scripts" in turn - high numbers first (K99) to low numbers last (K00). The point of all this is I renumbered the pcmcia "script" K24pcmcia to "above" the network script: K20network The result of this is the PCMCIA support is active before an attempt is made to start the network through the PCMCIA network card. Subtle, eh? (Maybe the order of start is the other way round and maybe the network "script" is called something else - but this is the broad idea). If someone could post the correct "rules for start up" or provide a link to where this is described - I feel confident (it hasn't failed yet) that this is a permanent fix to the intermittent problems of PCMCIA network support on Linux laptop Good luck Clive
I ran an up2date -u" last night on a freshly loaded FDC2 machine and noticed that the /etc/init.d/pcmcia file has been totally rewritten. Unfortunately, even though the yenta_socket now loads automatically, the network startup is unable to see the device pcnet_cs during the machines bootup sequence. I still have to do a "service network stop; service pcmcia restart; service network start" to get the network working. During bootup when the network loads I get the error "Bringing up interface eth0: pcnet_cs device eth0 does not seem to be present, delaying initialization. [FAILED]" When I restart the network using the commands I supplied aboe, this is the output I get on the screen : >>>service network stop (I didn't capture this output) >>>service pcmcia restart Shutting down PCMCIA services: ERROR: Module ds is in use by pcnet_cs ERROR: Module pcmcia_core is in use by yenta_socket,pcnet_cs,ds done. Starting PCMCIA services: service network cardmgr[2558]: open_sock (socket 2) failed: Bad file descriptor cardmgr[2558]: watching 2 sockets done. ip_tables: (C) 2000-2002 Netfilter core team >>>service network restart Shutting down interface eth0: [ OK ] Shutting down loopback interface: [ OK ] Setting network parameters: [ OK ] Bringing up loopback interface: ip_tables: (C) 2000-2002 Netfilter core team [ OK ] Bringing up interface eth0: ip_tables: (C) 2000-2002 Netfilter core team [ OK ] My network now works after the manual restart. It looks like the pcmcia file needs some more tinkering, but at least the yenta_socket driver now loads automatically !!!
Fedora Core 2 has now reached end of life, and no further updates will be provided by Red Hat. The Fedora legacy project will be producing further kernel updates for security problems only. If this bug has not been fixed in the latest Fedora Core 2 update kernel, please try to reproduce it under Fedora Core 3, and reopen if necessary, changing the product version accordingly. Thank you.