I think jim hits it soonest (this time in 36 hours) because he has a family of geeks and A 100Mbit connection from the internet. Now that the debloat script is changed to not muck with the defaults, this definitely looks like a bug upstream in the linux kernel.
I also note that I *thought* I'd squashed dscp to BE in the 3.10.36-4 SQM simplest.qos AND simple.qos code, but was very tired that day and probably missed something. Not that that helps - we managed to lock up the BE queue last time too. I don't know if the number of stations matter or the number of macs matter, or not. I will start even longer generation tests with more stations as soon as I can, but I'm kind of wiped out right now. ---------- Forwarded message ---------- From: Jim Gettys <[email protected]> Date: Fri, Apr 11, 2014 at 11:20 AM Subject: Re: [Cerowrt-devel] cerowrt-3.10.36-4 released To: Dave Taht <[email protected]> Unfortunately, the bug has recurred after a day and a half. root@cerowrt:/sys/kernel/debug/ieee80211/phy0/ath9k# cat queues (VO): qnum: 0 qdepth: 0 ampdu-depth: 0 pending: 0 stopped: 0 (VI): qnum: 1 qdepth: 0 ampdu-depth: 0 pending: 0 stopped: 0 (BE): qnum: 2 qdepth: 0 ampdu-depth: 0 pending: 0 stopped: 0 (BK): qnum: 3 qdepth: 0 ampdu-depth: 0 pending: 278 stopped: 1 (CAB): qnum: 8 qdepth: 0 ampdu-depth: 0 pending: 0 stopped: 0 _______________________________________________ Cerowrt-devel mailing list [email protected] https://lists.bufferbloat.net/listinfo/cerowrt-devel
