On Sun, Jun 28, 2009 at 09:23:29PM +0100, Sitsofe Wheeler wrote: > OK I'm still trying to follow this. I forwarded your patch to 2.6.31-rc1 > but this time I have kmemleak enabled. I left it streaming radio for the > past few hours and the following appeared in the logs: > > Jun 28 17:01:34 eeepc kernel: [ 744.083787] kmemleak: unreferenced object > 0xf5845770 (size 64): > Jun 28 17:01:34 eeepc kernel: [ 744.083795] kmemleak: comm "swapper", pid > 1, jiffies 4294673468 > Jun 28 17:01:34 eeepc kernel: [ 744.083799] kmemleak: backtrace: > Jun 28 17:01:34 eeepc kernel: [ 744.083811] kmemleak: [<c01a749d>] > kmemleak_alloc+0x11d/0x2a0 > Jun 28 17:01:34 eeepc kernel: [ 744.083818] kmemleak: [<c01a4376>] > __kmalloc+0x136/0x210 > Jun 28 17:01:34 eeepc kernel: [ 744.083828] kmemleak: [<c043f923>] > ieee80211_register_hw+0x83/0x4b0 [snip]
> There were quite a few leaks before this. I dunno if kmemleak is > spurious or not. As always, any ideas? I can't seem to boot a kmemleak kernel myself. But there were a number of fixes to kmemleak recently to track memory allocated in ieee80211_register_hw, IIRC -- so it would be good to know if this persists with all the latest fixes. As always, no ideas :( I'm guessing nothing in .31-rc has magically fixed any problems? I still say it's some kind of race condition made worse by the eeepc performance, but unless I can find one or replicate it with introduced load, I'm afraid I'm stumped. (Well, I guess we can always go off and rewrite the rx loop without the circular terminator and see how well that works on your HW.) -- Bob Copeland %% www.bobcopeland.com _______________________________________________ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
