Description of problem: NM takes long time [1min] to find the network interface after ACPI suspend/resume. This is with atheros [madwifi] driver where the driver is unloaded/reloaded via SUSPEND_MODULES="ath_pci" in /etc/pm/config.d/unload_modules Version-Release number of selected component (if applicable): NetworkManager-0.6.5-5.fc7 kernel-2.6.21-1.3228.fc7 dhclient-3.0.5-36.fc7 pm-utils-0.99.3-6.fc7 How reproducible: most of the time it takes app 1 min. Sometimes the detection is early Steps to Reproduce: 1. Install F7 on a thinkpad T40 with atheros, and enable NetworkManager 2. install madwifi from http://www.madwifi.org/ 3. echo 'SUSPEND_MODULES="ath_pci"' > /etc/pm/config.d/unload_modules 4. connect wireless to a AP [via NM] 5. Suspend the laptop [Fn-F4] 6. Resume [Fn] Actual results: NetworkManager shows a red cross for a min or so, then it starts spinning the activation icon. Expected results: The spinning should start within a few seconds after resume [not a min] Additional info: I understand that madwifi is unsupported [and ideally it should survive a suspend/resume cycle without unloading the driver]. But I'm guessing this issue could bite other wireless cards, whose drivers need unloading/reloading for suspend/resume. And I suspect the reason for this behavior is the bad interaction of 'dhclient' which automatically gets started with 'modprobe ath_pci' action. Its not clear if this a powermanagement issue or NetworkManager issue -[perhaps NM should check and shutdown this 'dhclient' action within 5sec? Hence filing it against NM]
Created attachment 157807 [details] /var/log/messages after resume from suspend
You have a quirk for suspend. You might need one to happen on resume? No idea about that card, maybe someone else knows. I really don't think NM is at fault though.
I wasn't thinking that it was a NM bug. The interaction between NM, dhclient & pm-utils is resulting in this behavior to the end user. I was hoping some robustness can be incorporated somewhere in the toolchain to avoid this.. I now realize that I had /etc/sysconfig/network-scripts/[ifcfg-ath0 and keys-ath0] files, [that were used before I attempted to use NM] These files were causing the 'dhclient' action at modprobe. On deleting these files, NM is able to detect ath0 immediately after resume. [I've tried this successfully with 4/5 suspend/resume cycles]. From my side this issue can be considered resolved [with a workaround] However I've noticed 2 other issues with NM. These are not critical for me - but if you wish to follow them up, I can file separate bugzilla entries for them. - mouse click on th NM applet gives a popup - that shows the currently available network choices. However this popup does not automatically refresh - when new wireless networks are detected. [I have to keep clicking on the NM applet to invoke a refresh] - I currently have 1 wire and 2 wireless networks listed on this applet. Both wireless networks are unencrypted. I've happended to switch from wired to wireless [perhaps more than once]. For the past many suspend resume attempts - NM does not automatically restart 'the previously active network connection'.[I've tried with both wired and wireless networks as the active connection before suspend]. I'm having to reselect the network-connection choice manually after resume.
Ah okay. I'll close this out then. > - mouse click on th NM applet gives a popup - that shows the currently > available network choices. However this popup does not automatically refresh - > when new wireless networks are detected. [I have to keep clicking on the NM > applet to invoke a refresh] Actually, clicking does invoke a rescan. The issue is that the menu isn't populated dynamically. This is filed upstream and I think is fixed in the unstable branch. > - I currently have 1 wire and 2 wireless networks listed on this applet. Both > wireless networks are unencrypted. I've happended to switch from wired to > wireless [perhaps more than once]. For the past many suspend resume attempts - > NM does not automatically restart 'the previously active network > connection'.[I've tried with both wired and wireless networks as the active > connection before suspend]. I'm having to reselect the network-connection choice > manually after resume. This probably should get a bug filed upstream at bugzilla.gnome.org. If you like, please file a bug there.