On 11/11/2010 10:26 AM, Ben Greear wrote:
On 11/11/2010 08:55 AM, Ben Greear wrote:
On 11/11/2010 01:27 AM, Tejun Heo wrote:
Hello,
On 11/11/2010 02:02 AM, Johannes Berg wrote:
I don't really see any deadlock here... hmm. Tejun, do you see anything
wrong with the "locking" in workq stuff here?
Something is holding the RTNL, and a bunch of other things are
trying to
acquire it. We don't really know who's holding it and who's
acquiring it
though.
I notice that the system is consistently running OOM, even though
it has 2GB RAM. I'll try disabling some of the memory-poisoning
debugging that may
be consuming excess amounts of RAM to see if that helps any.
The lockup (or extreme slowdown?) happens before the
serious memory pressure.
One thing I noticed is that at one point near (at?) the beginning
of the slowdown, it took 36-seconds to complete the
flush_work() call in ieee80211_do_stop in iface.c
From some printk's I added:
Nov 11 14:58:13 localhost kernel: do_stop: sta14 flushing work: e51298b4
Nov 11 14:58:49 localhost kernel: do_stop: sta14 flushed.
It is holding RTNL for this entire time, which of course stops
a large number of other useful processes from making
progress.
Is there any good reason for the flush to take so long?
Thanks,
Ben
--
Ben Greear <greearb@xxxxxxxxxxxxxxx>
Candela Technologies Inc http://www.candelatech.com
--
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
