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):
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,
initialization" at first, but now I can't even get the module to load.
Expected Results: Working WiFi-network
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
FATAL: Error inserting orinoco_cs
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
[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
*** 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.
*** 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
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
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,
(Maybe the order of start is the other way round and maybe the
network "script" is called something else - but this is the broad
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
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
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
Starting PCMCIA services: service network cardmgr: open_sock
(socket 2) failed: Bad file descriptor
cardmgr: watching 2 sockets
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.