Re: long delay for scan results after suspend

[Dan Williams <dcbw redhat com>]

On Thu, 2009-12-10 at 16:22 +0000, Daniel Drake wrote: 
> Hi,
> 
> 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.
> 
> When is NM expected to perform scans in this situation?

First thing to check is if the driver is failing the scan with -EBUSY or
something like that.  If it is, unfortunately wpa_supplicant doesn't
have a way to get that failure back to NetworkManager due to the way
that the supplicant is structured; the D-Bus call just schedules a scan
request and returns; there's no way to track the D-Bus call through the
scan request and return success/fail when the scan request actually gets
executed.  But if the request fails, the supplicant will schedule
another scan for 10 seconds later, so if the driver does fail the first
scan, you're looking at that 10-second backoff + 2 - 5 seconds of scan
time, plus latency in pushing the results from kernel -> supplciant ->
NM -> sugar (which won't be much but still noticable).

There are two ways to tackle the issue; (a) make sure the driver is
ready faster, or (b) make wpa_supplicant more intelligent about the
reasons for scan request failure and make it try again sooner depending
on the driver's returned error code.  I'd actually do both; (b) is
required anyway since some drivers seem to return EBUSY a lot (ath5k)
and thus make for very poor user experience.

Dan