pccard network interface is lost on resume (+ fix)

Bug #113755 reported by Tom May
8
Affects Status Importance Assigned to Milestone
acpi-support (Ubuntu)
Invalid
Medium
Daniel Hahler

Bug Description

Binary package hint: acpi-support

When I suspend then resume on an A31 Thinkpad with a Lucent Wavelan card, the Wavelan card's network interface is no longer configured.

The problem is in /etc/acpi/suspend.d/55-down-interfaces.sh. "pccardctl eject" results in the "eth1" interface going away, so when ifconfig is run to set INTERFACES, the resulting list does not include eth1, so the corresponding script /etc/acpi/resume.d/62-ifup.sh doesn't bring eth1 back up on resume. This can be fixed by running ifconfig to set INTERFACES before running pccardctl. Here's what my stock 55-down-interfaces.sh looks like:

#!/bin/sh

pccardctl eject

# Get rid of any currently running dhclients
killall dhclient dhclient3 2>/dev/null

# Find the currently running network interfaces...
INTERFACES=`/sbin/ifconfig | awk '/^[^ ]+/ {print $1}'`

# And shut them down
for x in $INTERFACES; do
    ifdown $x;
    ifconfig $x down;
done

This problem has unfortunately resulted in my kids thinking Linux is as junky as Windows.

Revision history for this message
Tom May (launchpad-sleepyhammer) wrote :

The fix I gave may not be correct, and it may not work all the time.

I checked my Debian system which does not have this problem, and it has an "allow-hotplug eth1" line in /etc/network/interfaces. Added this line to the Ubuntu system does not fix the problem. In any case, having resume bring up the same set of interfaces that were active on suspend seems most correct, so an allow-hotplug "fix" doesn't seem correct for any system.

My current fix is to add a resume.d script to do "ifdown eth1; ifup eth1".

Revision history for this message
Tom May (launchpad-sleepyhammer) wrote :

The ifdown/ifup doesn't always fix the problem either. Sadly, I'll be setting my kids' computer up with Debian instead of Ubuntu.

Revision history for this message
ankostis (ankostis) wrote :

I've fixed it simply by moving the discovery of the IFs prior to pcmcia-eject.

I hope that now this bug gets accepted and fixed ;)

Here is my '/etc/acpi/suspend.d/55-down-interfaces.sh' file:

#!/bin/sh

# Find the currently running network interfaces...
INTERFACES=`/sbin/ifconfig | awk '/^[^ ]+/ {print $1}'`

pccardctl eject

# Get rid of any currently running dhclients
killall dhclient dhclient3 2>/dev/null
rm /var/pid/dhclient.*.pid

# And shut them down
for x in $INTERFACES; do
    ifdown $x;
    ifconfig $x down;
done

Regards,
  Kostis

Revision history for this message
Tom May (launchpad-sleepyhammer) wrote :

Thanks for the comment. I wonder how many people have this problem? Somehow everything manages to work fine when I run debian unstable on the same system, and its 55-down-interfaces.sh sets INTERFACES after pccardctl eject:

#!/bin/sh

pccardctl eject

# Get rid of any currently running dhclients
killall dhclient dhclient3 2>/dev/null

# Find the currently running network interfaces...
INTERFACES=`/sbin/ifconfig | awk '/^[^ ]+/ {print $1}'`

# And shut them down
for x in $INTERFACES; do
    ifdown $x;
    ifconfig $x down;
done

Revision history for this message
Dlizzz (denis-lambolez) wrote :

Hi,

I had exactly the same problem and I found that the present bug is linked to this one : Bug #124499, first reported on 2007-07-07 by wildthewiz.
I used the following patch and now everything works fine :

/etc/udev/rules.d/85-ifupdown.rules

-#SUBSYSTEM=="net", DRIVERS=="?*", GOTO="net_start"
+SUBSYSTEM=="net", GOTO="net_start"

The problem came from Udev scripts for Network PCMCIA cards and not from ACPI suspend/resume scripts.

Regards,
Denis

Revision history for this message
Daniel Hahler (blueyed) wrote :

Thank you for your bug report and investigations.
I'm marking it as duplicate of bug 124499.

Please correct me, if I'm wrong. Thanks.

Changed in acpi-support:
assignee: nobody → blueyed
importance: Undecided → Medium
status: New → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Related questions

Remote bug watches

Bug watches keep track of this bug in other bug trackers.