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 _______________________________________________ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list