Re: long delay for scan results after suspend

[Dan Williams <dcbw redhat com>]

On Tue, 2009-12-29 at 12:41 +0000, Daniel Drake wrote:
> On Thu, 2009-12-10 at 16:22 +0000, Daniel Drake wrote:
> > With the new OLPC XO-1.5, our kernel driver fully powers down the
> > wireless device during suspend to the point where the kernel thinks the
> > SDIO card has been ejected.
> > 
> > It immediately comes back on resume, but there is a delay of
> > approximately 20 seconds before NM offers scan results to Sugar, which
> > is frustratingly long.
> 
> The delay isn't quite so severe, at least for me. I think we may have
> been seeing other problems.
> 
> However, we do still face a 4-5 second delay due to constructor() in
> nm-device.c:
> 
> 	/* Delay transition from UNMANAGED to UNAVAILABLE until we've given the
> 	 * system settings service a chance to figure out whether the device is
> 	 * managed or not.
> 	 */
> 	priv->start_timer = g_timeout_add_seconds (4, device_start, dev);

The comment should be pretty self-explanatory here; basically we need to
give some time for the system settings service to call out to HAL or
whatever and determine that the device should be managed.  NM can't
block on that because unmanaged devices is a property so that changed
signals can be emitted.

> Can we do better than that? For an aggressive-suspend setup like ours,
> having to wait this long for networks to crop up again is quite harmful
> to the user experience.

Not without risking race conditions and mismanaging devices that
shouldn't be managed, no...

> And just out of curiosity, is this any better in 0.8? I can see that the
> code has moved around quite a bit.

It is no longer a problem in 0.8 now that the system settings service
has been moved into NM itself.

Dan