Ticket #9854 (reopened defect)

Opened 5 years ago

Last modified 2 years ago

Scan is slow to happen after sleep with wireless off

Reported by: cjb Owned by: dsd
Priority: normal Milestone: 11.3.1
Component: power manager (powerd) Version: Development build as of this date
Keywords: Cc: sascha_silbe, sridhar
Action Needed: no action Verified: no
Deployments affected: Blocked By:
Blocking:

Description

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.

Change History

  Changed 5 years ago by cjb

  • owner changed from cjb to dsd
  • next_action changed from code to add to build

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

  Changed 5 years ago by 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.

  Changed 5 years ago by Quozl

  • next_action changed from add to build to diagnose

Need diagnosis of why it failed.

  Changed 5 years ago by Quozl

  • milestone changed from 1.5-software-final to 1.5-software-update

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.

  Changed 5 years ago by dsd

  Changed 5 years ago by Quozl

  • milestone changed from 1.5-software-later to 1.5-software-update

  Changed 5 years ago by dsd

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

follow-up: ↓ 9   Changed 4 years ago by Quozl

  • component changed from power manager (OHM) to power manager (powerd)

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.

in reply to: ↑ 8 ; follow-up: ↓ 10   Changed 4 years ago by 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?)

in reply to: ↑ 9   Changed 4 years ago by 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.

  Changed 4 years ago by cjb

Thanks, I understand now.

  Changed 4 years ago by 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.

  Changed 4 years ago by Quozl

  • milestone changed from 10.1.1 to 10.1.2

  Changed 4 years ago by Quozl

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

  Changed 4 years ago by sascha_silbe

  • cc sascha_silbe added

  Changed 4 years ago by dsd

  • milestone changed from 10.1.2 to 10.1.3

Not a regression, moving to next milestone

  Changed 4 years ago by 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).

  Changed 4 years ago by dsd

  • milestone changed from 11.2.0-M3 to 11.2.0-M4

  Changed 3 years ago by dsd

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

  Changed 3 years ago by sridhar

  • cc sridhar added

  Changed 3 years ago by Quozl

  • status changed from new to closed
  • next_action changed from diagnose to no action
  • resolution set to fixed

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.

  Changed 2 years ago by pgf

  • status changed from closed to reopened
  • resolution deleted
  • milestone changed from 11.2.0-M4 to 11.3.1

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.

  Changed 2 years ago by 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.

  Changed 2 years ago by 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.

  Changed 2 years ago by pgf

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

Note: See TracTickets for help on using tickets.