Scan is slow to happen after sleep with wireless off

[cjb]

When we resume after having turned off the wlan due to a power button press or lid close sleep, it takes a long time (~20 seconds) for NM to rescan and reconnect.

dsd suggests putting an "iwlist eth0 scan" in the resume path.

[cjb]

Fixed, please add the RPMs from http://koji.fedoraproject.org/koji/taskinfo?taskID=1867466 to the next build

[dsd]

Doesn't work, at least iwlist never appears in the process list when I watch it. (maybe it starts but immediately exits because it's being run too early?)

I think we should push this bug off until later. There is a 5 second delay visible in /var/log/messages before NM puts the device in state 2. That's what we should investigate.

[Quozl]

Need diagnosis of why it failed.

[Quozl]

Ticket moved out of 1.5-software-final to 1.5-software-update as a result of a software manufacturing release triage meeting. Per ed, dsd, cjb, reuben, quozl.

[dsd]

investigating the 5 second delay:

http://mail.gnome.org/archives/networkmanager-list/2009-December/msg00189.html

[dsd]

according to Dan's response, we don't have any choice here, this delay has to stay until NM-0.8

[Quozl]

Tested os202 with C1 and two C2.

• note IP address of laptop,
• use power button single press to direct suspend,
• wait for suspend to complete,
• use power button to wake and at the same time begin pinging the IP address the laptop had,
• measure the time taken before ping responds, as a measure of the time it takes to regain connectivity after directed suspend.

Results: 33s, 33s, 30s, 32s, 34s.

In the case of a laptop with power management enabled, it does not regain connectivity after wake if it is allowed to idle suspend.

[cjb]

Replying to Quozl:

In the case of a laptop with power management enabled, it does not regain connectivity after wake if it is allowed to idle suspend.

I don't follow. It *does* regain connectivity after wake if it idle-suspends, surely, because it doesn't lose connectivity across idle-suspend..

(Do you perhaps mean something else by idle-suspend?)

[Quozl]

Apologies, this is what I meant:

• laptop directed to suspend using power button, correctly disconnects from network,
• laptop directed to resume using power button,
• laptop autonomously idle-suspends before connectivity is restored.

So the time from being woken (using power button or lid switch) to achieving connectivity again is a minimum of 33 seconds, and maximum determined by how active the user is on keyboard and touchpad.

[cjb]

Thanks, I understand now.

[pgf]

btw, this came across the NM list today: http://mail.gnome.org/archives/networkmanager-list/2010-May/msg00016.html it's not worth backporting (i assume our NM uses dhclient) but it's something to look forward to.

[Quozl]

#10272 contains a possible simplified reproducer and may be a duplicate.

[dsd]

Not a regression, moving to next milestone

[martin.langhoff]

We have hardcoded delays in the iw and NM infra; that will have to wait until F14.

For the record -- I just tested on an XO-1.5 with aggressive suspend enabled.

• Associate to AP
• Close lid
• Open & press power button

Even though the reconnection times were long (40s, 50s), aggressive suspend does not get in the way.

The long delays break down to roughly: ~10s to initial list of APs, ~30s to a more complete list of APs (now including the relevant favourite), ~40s to completing association (using WEP).

[dsd]

Needs retesting on 11.2.0. F14 will have greatly helped this by removing the NM delay.

[Quozl]

Tested 11.2.0 os22, (using the time between wake from suspend using power button until ping response is seen from another host), delay is now six to seven seconds. This is adequate.

[pgf]

i think we've regressed on this, unless my particular machine is configured badly somehow (possible). from lid open to ping success i'm seeing 30 seconds.

[pgf]

note that while it isn't a problem with current default powerd configuration, this delay also affects wakeups from idle suspend where the screen has blanked (i.e. config_WLAN_WAKE_FROM_BLANK_IDLE_SLEEP="yes" in powerd.conf). i'm hoping this will become an issue in 12.1.0, when the laptop screen will be able to dim/blank even if suspend is inhibited.

[dsd]

Have you confirmed that there is a 30 second delay before the scan is fired, or are you just looking at the total time needed to re-establish the connection? I suspect you are hitting #10694 in this particular case.

[pgf]

thanks -- that's quite possibly what's happening.