On Thu, May 09, 2013 at 01:20:40PM -0700, Bill wrote: > What I see in the kmemleak file is that there are a large number of > entries like these: > > unreferenced object 0x815ec000 (size 4096): > comm "softirq", pid 0, jiffies 10639 (age 2200.640s) > hex dump (first 32 bytes): > 00 00 00 14 00 03 00 02 51 8b c8 57 00 00 0e 0b ........Q..W.... > 00 00 00 00 00 08 00 03 00 00 00 08 00 0a 00 06 ................ > backtrace: > [<800bf9d0>] __kmalloc+0x11c/0x16c > [<801c7b28>] __alloc_skb+0x74/0x140 > [<80d8c0c0>] _13+0x38/0xb8 [ath] > [<80dcf848>] _113+0x104/0x1034 [ath5k] > [<80dd127c>] _14+0xb04/0xb14 [ath5k] > > So it appears there are a large number of 4096-byte chunks that are > being abandoned by the ath5k driver.
Notice they all come through alloc_skb() [skb = 'socket buffer'], so these are all 802.11 frames / receive buffers. It's hard to say just from this output where the leak is and whether to blame ath5k or other layers. A minimal reproducing configuration would be pretty useful. -- Bob Copeland %% www.bobcopeland.com _______________________________________________ Devel mailing list [email protected] http://lists.open80211s.org/cgi-bin/mailman/listinfo/devel
