Red Hat Bugzilla – Bug 163311
3c574_cs-driven network card ceases to work shortly after update to pcmciautils
Last modified: 2014-03-16 22:54:54 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.8) Gecko/20050623 Fedora/1.0.4-5 Firefox/1.0.4
Description of problem:
The only network card on my ancient Toshiba Tecra 8100 is a 3com pcmcia card driven by 3c574_cs, using yenta_socket as the pcmcia (?) driver.
In the middle of today's rawhide update, right after pcmcia was removed, according to yum.log (long after pcmciautils was installed), the machine stopped responding to the network.
Booting it into a FC4 tree, the network card still works, so it wasn't a coincidental hardware failure.
I couldn't figure out how pcmcia is supposed to work with pcmciautils, but it certainly doesn't. I even reinstated /etc/sysconfig/pcmcia, that rpm had kindly saved aside, and /etc/init.d/network still references, to no avail.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Update (over the network, no less!) a box whose only network card is pcmcia from pcmcia-cs to pcmciautils
Actual Results: It stops functioning as soon as pcmcia is removed, and it won't come back up after a reboot.
Expected Results: I'd rather it kept working to complete the update, but failing that, a reboot should have fixed it.
I'm trying to revert to the previous version of pcmcia-cs, but that's a bit tricky, since hwdata conflicts with it.
If you've already booted, try running:
and then reloading the network driver.
Does that help?
/sbin/pcmcia-socket-startup 1 fixes it. I don't even have to run it with 0.
As soon as it runs, I can no longer unload 3c574_cs, because it's in use, and
ifconfig eth0 stops claiming there's no such device. From that point on,
service network restart brings eth0 up successfully.
I've added this command to /etc/sysconfig/network-scripts/ifcfg-eth0 (yeah, I
know :-), and the box is now happy. Is there anywhere else that should be
running this command but isn't, or at least not in a way that it has the desired
It should get run automatically when yenta_socket (or whatever socket driver you
use) is loaded.
Sorry to barge in, but I am having trouble with the same card on FC4: it fails
to come up with "eth0: interrupt(s) dropped" in dmesg.
Is there a fix for that? Should I open another bug?
PS: I found http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=270376 via google,
which seems to be related.
Again, Sorry for the intrusion.
Yes, that should be a different bug, filed against 'kernel'.
I suppose this would be from /etc/udev/rules.d/pcmcia.rules, right? If so, it's
missing the `1' argument to pcmcia-socket-startup. Adding it fixes the problem,
even after I remove my hack erm work-around in ifcfg-eth0.
When it's run from the udev rule, it pulls the socket number from the environment.
Then I guess there's something wrong with the code that handles SOCKET_NO from
the environment. If I wrap pcmcia-socket-startup with a script that runs the
original program with $SOCKET_NO as the only argument, everything works. I also
added logging to the wrapper and I see two invocations, one with SOCKET_NO=0 and
one with SOCKET_NO=1.
Created attachment 117033 [details]
actually use $SOCKET_NO if cmd line arg is missing
D'oh! It's no use to parse $SOCKET_NO into the socket variable if it's going
to be unconditionally overwritten with the result of parsing a cmd line
argument that's not even there! :-) This patch applies to pcmciautils-006-1.
Wow, that logic was ... impressive.
Fixed in -2.
The fix is correct, but not enough to get it to work, unfortunately.
Somehow, pcmcia-socket-startup gets passed a single argument in the command
line, and the argument is `pcmcia-socket', even though
The unexpected argument (you can easily tell where it came from) breaks the
existing (fixed) logic in pcmcia-socket-startup, and might break other programs
that expect no arguments in the command line from udev. Looks like some ugly
bug in udev, so, changing component...
Actually, it's the expected behavior for a hotplug rule. Will have to code around.
Created attachment 117115 [details]
Here's a patch, against 006-2/007-upstream to fix the logic.
Fixed in 007-1.
Confirmed, it works now, thanks!