Bug 163311
Summary: | 3c574_cs-driven network card ceases to work shortly after update to pcmciautils | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Alexandre Oliva <oliva> | ||||||
Component: | pcmciautils | Assignee: | Bill Nottingham <notting> | ||||||
Status: | CLOSED RAWHIDE | QA Contact: | |||||||
Severity: | medium | Docs Contact: | |||||||
Priority: | medium | ||||||||
Version: | rawhide | CC: | jfontain, notting, rvokal | ||||||
Target Milestone: | --- | ||||||||
Target Release: | --- | ||||||||
Hardware: | i686 | ||||||||
OS: | Linux | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | 007-1 | Doc Type: | Bug Fix | ||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2005-07-25 02:24:59 UTC | Type: | --- | ||||||
Regression: | --- | Mount Type: | --- | ||||||
Documentation: | --- | CRM: | |||||||
Verified Versions: | Category: | --- | |||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Attachments: |
|
Description
Alexandre Oliva
2005-07-15 00:08:14 UTC
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! |