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. Suggestions? Version-Release number of selected component (if applicable): pcmciautils-005-1 kernel-2.6.12-1.1432_FC5.i686 How reproducible: Didn't try 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. Additional info: 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: /sbin/pcmcia-socket-startup 0 /sbin/pcmcia-socket-startup 1 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 effect?
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 /etc/udev/rules.d/pcmcia.rules says: SUBSYSTEM="pcmcia_socket" RUN+="/sbin/pcmcia-socket-startup" 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] patch Here's a patch, against 006-2/007-upstream to fix the logic.
Fixed in 007-1.
Confirmed, it works now, thanks!