Red Hat Bugzilla – Bug 60205
pcmcia confused about network interfaces on Dell Latitude C610
Last modified: 2015-01-04 17:01:43 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.76 [en] (X11; U; SunOS 5.8 sun4u)
Description of problem:
On Dell Latitude C610 with built-in ethernet and mini-pci wireless card, I have
problems controlling the two interfaces separately. eth1 (wireless) will not
start unless eth0 (ether) is up. eth0 will not start if pcmcia is running.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Set up /etc/sysconfig/ifcfg-eth1 by hand (see bug 56647). Set ONBOOT=no for
both eth0 and eth1.
2. Pick a scenario below.
2. "ifup eth0"
2. "ifup eth1"
Actual Results: Scenario 1: eth0 (which is dhcp) hangs and eventually times
Scenario 2: No-op (eth1 does not come up, no message, no hang, no network).
Expected Results: Scenario 1: eth0 should receive it's dhcp information and
Scenario 2: eth1 should receive it's dhcp information and start.
Scenario 1: I can get eth0 to start by executing "service pcmcia stop" followed
by "ifup eth0".
Scenario 2: I can get eth1 to start by executing "service pcmcia stop" followed
by "ifup eth0" (but must have cable plugged in), followed by "service pcmcia
If I try to "service pcmcia restart" when eth0 is running, log messages indicate
that the network attempts to start eth0, but if eth0 is already running, it
Update: With 7.3, the problem does not occur in most cases, however there is
still one problem scenario left.
On resuming after suspend to RAM, eth1 does not come up. In order to get it to
come up, I need to perform the steps listed above (and recapped below):
(1) service pcmcia stop
(2) ifup eth0 (with no cable attached)
(3) service pcmcia start
(4) ifup eth1
All other scenarios tested so far seem to work in 7.3.
question: does it help if you add
to the end of the line with "vmlinuz" in the /etc/grub/grub.conf file ?
I tried the following: Set resume=force, set eth0 down and eth1 up. Suspend and
resume. The effect is that eth0 attempts to start (which it should not do,
since it was down at suspend). When eth0 times out, eth1 starts.
So yes, resume=force seems to help, but the behavior is still not perfect. It
seems like I would want things that were down to stay down and things that were
up to attempt to come up on resume. Perhaps this is repated to bug 47529?
This is still the behavior in RHL 8.0.