Bug 245640 - NetworkManager takes long time [1min] to find the network interface after ACPI suspend/resume
NetworkManager takes long time [1min] to find the network interface after ACP...
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: NetworkManager (Show other bugs)
7
All Linux
low Severity low
: ---
: ---
Assigned To: Christopher Aillon
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-06-25 16:17 EDT by Satish Balay
Modified: 2007-11-30 17:12 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-06-25 17:37:14 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
/var/log/messages after resume from suspend (9.53 KB, text/plain)
2007-06-25 16:17 EDT, Satish Balay
no flags Details

  None (edit)
Description Satish Balay 2007-06-25 16:17:22 EDT
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]
Comment 1 Satish Balay 2007-06-25 16:17:23 EDT
Created attachment 157807 [details]
/var/log/messages after resume from suspend
Comment 2 Christopher Aillon 2007-06-25 16:31:04 EDT
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.
Comment 3 Satish Balay 2007-06-25 17:27:16 EDT
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.
Comment 4 Christopher Aillon 2007-06-25 17:37:14 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.