On Wed, Mar 04, 2009 at 07:07:59AM -0500, Bob Copeland wrote: > On Tue, Mar 03, 2009 at 08:03:52PM +0000, Sitsofe Wheeler wrote: > > None. Perhaps it's wishful thinking but a function trace for the few > minutes prior to the poison would be useful. A good replicator might > be to run a sequence of automatic suspend/resume with pm_test, in > parallel with iwlist wlan0 scan (as root, so scans are actually > performed), in parallel with iperf or ping. I didn't personally have > luck with that workload, though. Forcing the scans and pings didn't seem to make the issue occur. Unfortunately I can't quite provide you what you were asking for... I started the function_tracer feature in /sys/kernel/debug/tracing and put the buffer size to 153600kb (previously I had set it higher and successfully OOMd my box : ). Unfortunately I had no filter so this was not enough for all that long of a log (maybe about 6 seconds). I had a small script that did the following: watch -n1 'if `tail -1000 /var/log/kern.log | grep -q Poison`; then echo 0 > /sys/kernel/debug/tracing/tracing_on; cat /sys/kernel/debug/tracing/trace | gzip > /tmp/trace.txt.gz ; fi' (the script is obviously flawed but it did the job) I've put up results on http://sucs.org/~sits/test/eeepc-debug/20090306/ and I think the type that kmalloc notices is 4154504125.579778 . There is also a pre grepped log of (ieee|ath5k) in that directory. I'll try and act on your filtering suggestions next time but I didn't have too much time to get this going... -- Sitsofe | http://sucs.org/~sits/ -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
