On Wed, 2009-02-04 at 15:40 -0800, Howard Chu wrote: > Dan Williams wrote: > > On Wed, 2009-02-04 at 18:04 -0500, Tony Espy wrote: > >> Dan Williams wrote: > >>> So here's why old access points show up after resume... > >>> > >>> Executive summary: exclusively a *driver* problem > >>> > >>> > >>> Detailed explanation: > >>> > >>> Most kernel drivers use 'jiffies' as the timestamp for each scan result. > >>> jiffies is a kernel counter that counts *while the kernel is alive*, and > >>> thus does not reflect time spent in suspend and hibernate. > >>> > >>> When the supplicant requests scan results from the driver on resume, the > >>> supplicant (and NM) gets back a list of scan results with recent-looking > >>> timestamps that do not reflect the time the machine was suspended. > >>> > >>> The solutions are to move drivers to using the actual machine clock (the > >>> kernel equivalent of time(2)) for last_beacon, or to be more agressive > >>> about expiring entries on resume with something like (10 - time spent in > >>> sleep). > > OK. Having looked in my wireless-testing tree, I see that most of the drivers > are now just allowing mac80211 to handle scanning, so this is not a > per-driver > issue. At least that makes the scope of fixing easier to manage. > > >> How 'bout getting drivers to add code to their resume functions that > >> just clears the scan results queue? > > I was actually thinking it makes sense to clear results on suspend, no reason > to keep kmem allocated at that point. (No point in saving an obsolete queue > on > a hibernate, after all.) > > > That's not desirable on mobile platforms like OLPC that do > > suspend/resume very quickly and very often. The best mechanism is to > > make the *actual* last seen time available to the userspace programs > > that implement the policy (like connection managers) so they can do > > what's appropriate. > > OK. I suggest a compromise then, since fetching kernel time will also be > expensive if done frequently - just fetch it at driver load and resume time, > and store it as a <base> in the driver. Cache entries then store base+jiffy. > This allows cache stamps to continue to be cheap, but also solves the > sleep/resume mismatch.
Yeah, that might work. Want to whip up a quick patch we can use for further discussion? Dan _______________________________________________ NetworkManager-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/networkmanager-list
