Am Dienstag 29 Juni 2010 schrieb David Ellingsworth: > I haven't conducted any other tests beyond what was bisected in the > attached log. Performance across all those revisions remained somewhat > fast, and my markings were based solely on client link failure. Each > bad commit resulted in the link failing after about 10s while > transferring a file. At which point, the transfer would stop, the AP > would be unreachable via pings, but the client remained associated to > the AP. About 30s after that point, the client would timeout and > re-associate to the AP reactivating the link. Could you please check if the queues get stuck in that situation? I was able to sometimes observe queues getting stuck on rt2800. Just do the following (on the AP mode machine): mount -t debugfs none /sys/debug cat /sys/debug/ieee80211/phy0/queues That should give you something like: 00: 0x00000000/0 01: 0x00000000/0 02: 0x00000000/0 03: 0x00000000/0 And if there's somewhere a 1 instead of a 0 it means that this queue is stopped (which can/and must actually happen in some scenarios without causing problems). If that 1 stays there for longer that means something didn't start the queue anymore and your connection is most likely stuck. Helmut -- 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
