Removing /etc/udev/rules.d/70-persistent-net.rules and rebooting does
mean that I can now successfully suspend and resume and my wireless
still works. You don't say how you found out about this, or whether it
is a known bug or not (I can't find duplicates on a search for 70
-persistent-net.rules),
I had somehow the same problem. But I don't think it is a pm-utils
problem it is just triggered through suspend/resume.
You have a udev problem, because following in your dmesg output:
wlan0_rename
and after resume:
wmaster0
Solution:
Remove the following file it gets regenerated after the nex
wlan0_rename coming back up happens at 8.897105, a short time after
resuming.
With 0.99.2-3ubuntu6, I have waited for ten minutes (I checked with
sleep 600, this is not an estimate) with no sign of "iwlist scan"
returning any APs (there are three visible usually) and network manager
not budging.
** Attachment added: "dmesg output after booting, using pm-utils
0.99.2-3ubuntu5"
http://launchpadlibrarian.net/12955667/dmesg-afterbootubuntu5.log
--
Upgrade from 0.99.2-3ubuntu5 to 0.99.2-3ubuntu6 breaks wireless after resume
(iwl3945)
https://bugs.launchpad.net/bugs/208103
You received t
It does seem odd all round. My network driver worked fine in Gutsy, but
that was ipw3945, not iwl3945. I will try suspending and resuming with
ubuntu5 and ubuntu6 and see if there are differences in the logs. I see
the evidence of the driver resuming, but "iwlist scan" never returns any
results aft
One of the changes in 0.99.2-3ubuntu6 is to unload network driver modules
before suspending, as some of them can prevent suspends from working correctly.
For what it's worth, this behaviour of removing network drivers is how gutsy
worked. Oddly, your dmesg looks like the driver gets reloaded and
