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): How reproducible: Always 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. Scenario 1: 2. "ifup eth0" Scenario 2: 2. "ifup eth1" Actual Results: Scenario 1: eth0 (which is dhcp) hangs and eventually times out. 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 start. Scenario 2: eth1 should receive it's dhcp information and start. Additional info: 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 start". 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 starts eth1.
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 resume=force 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.