Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 163311 - 3c574_cs-driven network card ceases to work shortly after update to pcmciautils
Summary: 3c574_cs-driven network card ceases to work shortly after update to pcmciautils
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: pcmciautils
Version: rawhide
Hardware: i686
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-07-15 00:08 UTC by Alexandre Oliva
Modified: 2014-03-17 02:54 UTC (History)
3 users (show)

Fixed In Version: 007-1
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-07-25 02:24:59 UTC


Attachments (Terms of Use)
actually use $SOCKET_NO if cmd line arg is missing (deleted)
2005-07-21 20:28 UTC, Alexandre Oliva
no flags Details | Diff
patch (deleted)
2005-07-25 02:22 UTC, Bill Nottingham
no flags Details | Diff

Description Alexandre Oliva 2005-07-15 00:08:14 UTC
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.

Comment 1 Bill Nottingham 2005-07-15 16:16:13 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?

Comment 2 Alexandre Oliva 2005-07-21 04:50:36 UTC
/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?

Comment 3 Bill Nottingham 2005-07-21 04:58:37 UTC
It should get run automatically when yenta_socket (or whatever socket driver you
use) is loaded.

Comment 4 Jean-Luc Fontaine 2005-07-21 15:42:11 UTC
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.

Comment 5 Bill Nottingham 2005-07-21 16:12:08 UTC
Yes, that should be a different bug, filed against 'kernel'.

Comment 6 Alexandre Oliva 2005-07-21 17:05:24 UTC
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.

Comment 7 Bill Nottingham 2005-07-21 17:14:25 UTC
When it's run from the udev rule, it pulls the socket number from the environment.

Comment 8 Alexandre Oliva 2005-07-21 20:09:10 UTC
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.

Comment 9 Alexandre Oliva 2005-07-21 20:28:56 UTC
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.

Comment 10 Bill Nottingham 2005-07-21 20:44:44 UTC
Wow, that logic was ... impressive.

Fixed in -2.

Comment 11 Alexandre Oliva 2005-07-23 12:54:42 UTC
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...

Comment 12 Bill Nottingham 2005-07-25 02:09:47 UTC
Actually, it's the expected behavior for a hotplug rule. Will have to code around.

Comment 13 Bill Nottingham 2005-07-25 02:22:14 UTC
Created attachment 117115 [details]
patch

Here's a patch, against 006-2/007-upstream to fix the logic.

Comment 14 Bill Nottingham 2005-07-25 02:24:59 UTC
Fixed in 007-1.

Comment 15 Alexandre Oliva 2005-07-25 17:35:42 UTC
Confirmed, it works now, thanks!


Note You need to log in before you can comment on or make changes to this bug.