On Tue, Jun 18, 2013 at 6:35 AM, Toke Høiland-Jørgensen <[email protected]> wrote: > Toke Høiland-Jørgensen <[email protected]> writes: > >> I'm getting some weird errors in dmesg on my latest cero(-based) build: >> >> [75667.492187] ath: phy0: Failed to stop TX DMA, queues=0x004! >> [75667.574218] ath: phy0: Failed to stop TX DMA, queues=0x004! >> [75667.660156] ath: phy0: Failed to stop TX DMA, queues=0x004! >> [75667.742187] ath: phy0: Failed to stop TX DMA, queues=0x004! >> [75667.828125] ath: phy0: Failed to stop TX DMA, queues=0x004! >> [78593.152343] ath: phy0: Failed to stop TX DMA, queues=0x004! >> [78600.367187] ath: phy0: Failed to stop TX DMA, queues=0x004! > > Something is definitely dodgy with the wireless. I can only see the
You are aware of the bssid trick right? > different networks intermittently, and when I try to connect, I get this > in the logs: > > Jun 18 15:31:33 guardian daemon.notice hostapd: sw10: STA 00:21:5c:51:c1:ad > IEEE 802.11: did not acknowledge authentication response > Jun 18 15:31:33 guardian daemon.info hostapd: sw10: STA 00:21:5c:51:c1:ad > IEEE 802.11: associated (aid 1) > Jun 18 15:31:34 guardian daemon.info hostapd: sw10: STA 00:21:5c:51:c1:ad > RADIUS: starting accounting session 51BE2E3B-00000000 > Jun 18 15:31:34 guardian daemon.info hostapd: sw10: STA 00:21:5c:51:c1:ad > WPA: pairwise key handshake completed (RSN) > Jun 18 15:31:37 guardian daemon.info dnsmasq-dhcp[2782]: DHCPDISCOVER(sw10) > 00:21:5c:51:c1:ad > Jun 18 15:31:37 guardian daemon.info dnsmasq-dhcp[2782]: DHCPOFFER(sw10) > 10.42.3.101 00:21:5c:51:c1:ad > Jun 18 15:31:37 guardian daemon.info dnsmasq-dhcp[2782]: DHCPREQUEST(sw10) > 10.42.3.101 00:21:5c:51:c1:ad > Jun 18 15:31:37 guardian daemon.info dnsmasq-dhcp[2782]: DHCPACK(sw10) > 10.42.3.101 00:21:5c:51:c1:ad alrua-laptop > Jun 18 15:31:37 guardian daemon.info dnsmasq-dhcp[2782]: RTR-ADVERT(sw10) > xxxx.xxxx.xxxx:4:: > Jun 18 15:31:44 guardian daemon.notice hostapd: sw10: STA 00:21:5c:51:c1:ad > IEEE 802.11: did not acknowledge authentication response > Jun 18 15:31:44 guardian daemon.notice hostapd: sw10: STA 00:21:5c:51:c1:ad > IEEE 802.11: did not acknowledge authentication response > > > On a second try it succeeds, however I still can't connect to the 2.4ghz > net... > > > -Toke > > _______________________________________________ > Cerowrt-devel mailing list > [email protected] > https://lists.bufferbloat.net/listinfo/cerowrt-devel > I have seen many errors like that off and on over the years. Felix has put in many a patch in the driver to keep bad things from happening like that. I think this is the background queue acting up on you. I note that the cerowrt qlen_bk is 12 packets. Perhaps there's an issue in tracking that correctly in the latest openwrt? I too am seeing it under heavy load. I have not been seeing it on boxes that I'm killing multi-queue wifi on (which really seems to be a huge win regardless). This is not a "fix": #!/bin/sh ipt() { iptables $* ip6tables $* } #iptables doesn't support an inverted match #iptables -t mangle -A PREROUTING -m dscp ! --dscp-class BE -j DSCP --set-dscp 0 ipt -t mangle -N FIX_TOS ipt -t mangle -A FIX_TOS -m dscp --dscp-class BE -j ACCEPT ipt -t mangle -A FIX_TOS -j DSCP --set-dscp 0 ipt -t mangle -A POSTROUTING -o wlan0 -j FIX_TOS -- Dave Täht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html _______________________________________________ Cerowrt-devel mailing list [email protected] https://lists.bufferbloat.net/listinfo/cerowrt-devel
