"link is not ready" when resuming from suspend with ipw3945

[John Ray]

Binary package hint: linux-restricted-modules-common

I have an Acer Aspire 5630 laptop with wireless networking and Gutsy Gibson installed (upgraded from feisty fawn). When I suspend and then resume the computer I get a warning saying that there was an error resuming. The issue seems to be with the wireless networking. Here is the log

Oct 18 22:34:44 ray-laptop kernel: [ 345.176000] ADDRCONF(NETDEV_UP): eth1: link is not ready
Oct 18 22:34:44 ray-laptop kernel: [ 345.180000] ACPI: Thermal Zone [TZ01] (53 C)
Oct 18 22:34:44 ray-laptop avahi-daemon[5731]: Joining mDNS multicast group on interface eth1.IPv4 with address 192.168.2.113.
Oct 18 22:34:44 ray-laptop avahi-daemon[5731]: New relevant interface eth1.IPv4 for mDNS.
Oct 18 22:34:45 ray-laptop avahi-daemon[5731]: Registering new address record for 192.168.2.113 on eth1.IPv4.
Oct 18 22:34:45 ray-laptop kernel: [ 345.260000] ACPI: AC Adapter [ACAD] (on-line)
Oct 18 22:34:45 ray-laptop kernel: [ 345.408000] ACPI: Battery Slot [BAT1] (battery present)
Oct 18 22:34:45 ray-laptop kernel: [ 345.448000] INPUT packet died: IN=eth1 OUT= MAC= SRC=192.168.2.113 DST=224.0.0.251 LEN=235 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=UDP SPT=5353 DPT=5353 LEN=215
Oct 18 22:34:45 ray-laptop anacron[7707]: Anacron 2.3 started on 2007-10-18
Oct 18 22:34:45 ray-laptop anacron[7707]: Normal exit (0 jobs run)
Oct 18 22:34:45 ray-laptop kernel: [ 345.492000] INPUT packet died: IN=eth1 OUT= MAC= SRC=192.168.2.113 DST=224.0.0.251 LEN=145 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=UDP SPT=5353 DPT=5353 LEN=125
Oct 18 22:34:45 ray-laptop kernel: [ 345.700000] INPUT packet died: IN=eth1 OUT= MAC= SRC=192.168.2.113 DST=224.0.0.251 LEN=235 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=UDP SPT=5353 DPT=5353 LEN=215
Oct 18 22:34:48 ray-laptop kernel: [ 348.420000] ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
Oct 18 22:34:50 ray-laptop avahi-daemon[5731]: Registering new address record for fe80::218:deff:fe4c:e713 on eth1.*.

The first line "eth1: link is not ready" seems to be where the error occurs. However 4 seconds later the network card comes up again and I am able to surf the web fine. Although my routes are screwed up. Normally after a boot they look like this

Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.2.0 * 255.255.255.0 U 0 0 0 eth1
link-local * 255.255.0.0 U 1000 0 0 eth1
default 192.168.2.1 0.0.0.0 UG 100 0 0 eth1

However after this suspend problem it is

Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.2.0 * 255.255.255.0 U 0 0 0 eth0
192.168.2.0 * 255.255.255.0 U 0 0 0 eth1
link-local * 255.255.0.0 U 1000 0 0 eth0
default 192.168.2.1 0.0.0.0 UG 100 0 0 eth1
default 192.168.2.1 0.0.0.0 UG 100 0 0 eth0

NOTE: eth1 is my wireless and eth0 is my wired connection which should be disabled. With the above routing table I'm able to access the internet but not my local LAN. I'm not really sure why it add routes for eth0. If I do a /etc/init.d/networking restart after suspending then it of course fixes the routing table back to having just the 3 lines.

It seems to me that the wireless is resuming fine however it just takes a few seconds. In /etc/modprobe.d/ipw3945 there's this section

install ipw3945 /sbin/modprobe --ignore-install ipw3945 ; sleep 0.5 ; \
 /sbin/ipw3945d-$(uname -r) --quiet

I added on a sleep at the end so it looks like this

install ipw3945 /sbin/modprobe --ignore-install ipw3945 ; sleep 0.5 ; \
 /sbin/ipw3945d-$(uname -r) --quiet ; sleep 5.0

With this change everything works fine. My resume log doesn't have any errors and I don't get a pop-up window telling me there was a problem suspending. Also my routing table is fine.

I'm relatively new to Linux so I'm not really sure what the proper fix for this is. The sleep seems like a bit of a hack as you don't really know how long to sleep for. On my system looking at the logs from a few failed suspends you seem to need delays of from 0.7 to 4 seconds. But I imagine slower machines or just random chance will sometimes mean this isn't enough. Doing a sleep of 20 seconds which should work on all systems seems unacceptable. Maybe ipw3945 needs to be fixed so that it doesn't return until things are up and running.

[Bryce Harrington (bryce)]

Hi john-nospam,

Thank you for taking the time to report this bug and helping to make Ubuntu better. You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering is this still an issue for you? Can you try with the latest development release of Ubuntu? (ISOs are available from cdimage.ubuntu.com)

If it remains an issue, could you also attach a new /var/log/Xorg.0.log?
Thanks in advance.

The output of lspci -vvnn would also be worth having.

[John Ray (john-nospam)]

I wiped my hard drive and installed a fresh copy of Hardy and this is mostly working for me now. I also switched from a manual network configuration to a roaming profile using the NetworkManager. Anyway, the network does eventually get going but it can take anywhere from 30 seconds to over 5 minutes for the NetworkManager to find my network.

However I noticed that if the network hadn't started after a couple minutes then executing a "sudo iwlist scanning" a few times from the command line until my home network is found will cause the networking to be configured right after that. It seems similar to this issue https://bugs.launchpad.net/ubuntu/feisty/+source/network-manager/+bug/40125/comments/56

I also found that going into my linksys router settings and enabling the "Wireless SSID Broadcast" (I previously had it disabled) has cut the network startup time down to a consistent 30-45 seconds after resume. Although I can also execute a "sudo iwlist scanning" and get it going in only a few seconds instead of waiting the 30-45 seconds.

[Sergio Zanchetta (primes2h)]

The 18 month support period for Gutsy Gibbon 7.10 has reached its end of life -
http://www.ubuntu.com/news/ubuntu-7.10-eol . As a result, we are closing the
linux-restricted-modules-2.6.22 task. It would be helpful if you could test the
new Jaunty Jackalope 9.04 release and confirm if this issue remains -
http://www.ubuntu.com/getubuntu/releasenotes/904overview. If the issue still exists with the Jaunty
release, please update this report by changing the Status of the "linux (Ubuntu)"
task from "Incomplete" to "New". Thanks in advance.