[OpenWrt-Devel] mt76 issues on 18.06 HEAD - was: 18.06.2 branching/builds

[Stijn Segers]

Op woensdag 30 januari 2019 om 23:46 schreef Stijn Segers 
<foss at volatilesystems.org>:
> 
> Op woensdag 30 januari 2019 om 18:17 schreef Felix Fietkau 
> <nbd at nbd.name>:
>> On 2019-01-30 16:58, Stijn Segers wrote:
>>>  Hi Jo, Felix,
>>> 
>>>  Far be it from me to pretend this issue might have a larger impact 
>>> than
>>>  I myself can assess, but Felix has been bumping mt76 on the 18.06
>>>  branch, and those bumps have broken my 18.06.1+ mt7621 wireless [1]
>>>  (and, judging from Flyspray, at least one other person's as well).
>>> 
>>>  I have no idea how many people are running both mt7621 and 18.06 
>>> HEAD
>>>  (like me and the other guy), so this might be an isolated issue, 
>>> but I
>>>  do know wireless craps out on me within a few minutes and the AP 
>>> needs
>>>  to be brought up again; it's not just a matter of worse 
>>> performance but
>>>  outright disconnection.
>>> 
>>>  So I'd like to ask if 18.06.2 could be released with a fix/with 
>>> those
>>>  mt76 rolled back.
>> Hey Stijn,
>> 
>> Thanks for bringing this to my attention again.
>> Could you please test the two attached patches individually with the
>> latest 18.06 branch to see if either of them resolves your issue?
>> 
>> I've been doing a lot of tests lately with both MT7603 and MT7612E on
>> MT7621, and I have been unable to reproduce your issues so far.
>> 
>> Thanks,
>> 
>> - Felix
> 
> Thanks Felix, will give both a shot and report back.
> 
> Jo: I kind of hoped to catch Felix on IRC but that didn't happen, in 
> hindsight I should have pinged you as well about this, but there's 
> probably other bugs pending people would consider showstoppers for a 
> point release... Would probably only have delayed it.
> 
> Vielen Dank!
> 
> Stijn

Hi Felix,

I built 18.06 HEAD with your 2019-01-30 bump, and with the 
mt76-disable-edcca.patch applied. That seemed very stable (up since 
30/01 evening, very high throughput - never seen anything close to 50 
MBps on my 2x2 client before; I barely got close to 25 MBps before). No 
laggy feeling, so didn't check ping. Wireless wasn't used in the 
morning or the day, but I have tried to stress it in the evening 
(31/01) -transferred about 65 GiB of data over the WLAN (scp). No 
hiccups whatsoever.

I then reverted to vanilla 18.06 HEAD 31/01, so none of the patches 
applied, and the connection kept working but page loading in the 
browser e.g. would occasionally be slow (nothing else chewing on my 
network connection). I checked ping, and it was all over the place 
again (from sub-milliseconds to 10 ms, occasionally 100ms to other 
devices on the LAN). I suppose there's no real value in those numbers, 
but it does quantify the feeling of the wireless 'choking' momentarily, 
then picking up again. After like half an hour, wireless would hang on 
my laptop: I was unable to ping anything, web pages stopped loading 
altogether. Same thing on my smartphone. However, when I disabled 
wireless on both clients, then turned it on again, the connection 
started working once more; that didn't happen on the previous mt76 
bumps. There the radio would just seem to die like explained in the bug 
report.

Logread doesn't show much, filtered for my laptop's MAC e.g. (I killed 
the wireless around 22:46):

Thu Jan 31 21:32:53 2019 daemon.info hostapd: wlan0: STA 
a4:xx:xx:xx:6e:0f IEEE 802.11: authenticated
Thu Jan 31 21:32:53 2019 daemon.info hostapd: wlan0: STA 
a4:xx:xx:xx:6e:0f IEEE 802.11: associated (aid 1)
Thu Jan 31 21:32:53 2019 daemon.notice hostapd: wlan0: AP-STA-CONNECTED 
a4:xx:xx:xx:6e:0f
Thu Jan 31 21:32:53 2019 daemon.info hostapd: wlan0: STA 
a4:xx:xx:xx:6e:0f WPA: pairwise key handshake completed (RSN)
Thu Jan 31 21:32:53 2019 daemon.info dnsmasq-dhcp[3793]: 
DHCPREQUEST(br-lan) 10.0.0.5 a4:xx:xx:xx:6e:0f
Thu Jan 31 21:32:53 2019 daemon.info dnsmasq-dhcp[3793]: 
DHCPACK(br-lan) 10.0.0.5 a4:xx:xx:xx:6e:0f icarus
Thu Jan 31 22:36:53 2019 daemon.info hostapd: wlan0: STA 
a4:xx:xx:xx:6e:0f IEEE 802.11: authenticated
Thu Jan 31 22:36:54 2019 daemon.info hostapd: wlan0: STA 
a4:xx:xx:xx:6e:0f IEEE 802.11: associated (aid 1)
Thu Jan 31 22:36:54 2019 daemon.notice hostapd: wlan0: AP-STA-CONNECTED 
a4:xx:xx:xx:6e:0f
Thu Jan 31 22:36:54 2019 daemon.info hostapd: wlan0: STA 
a4:xx:xx:xx:6e:0f WPA: pairwise key handshake completed (RSN)
Thu Jan 31 22:46:58 2019 daemon.notice hostapd: wlan0: 
AP-STA-DISCONNECTED a4:xx:xx:xx:6e:0f
Thu Jan 31 22:47:10 2019 daemon.info hostapd: wlan0: STA 
a4:xx:xx:xx:6e:0f IEEE 802.11: authenticated
Thu Jan 31 22:47:10 2019 daemon.info hostapd: wlan0: STA 
a4:xx:xx:xx:6e:0f IEEE 802.11: associated (aid 1)
Thu Jan 31 22:47:10 2019 daemon.notice hostapd: wlan0: AP-STA-CONNECTED 
a4:xx:xx:xx:6e:0f
Thu Jan 31 22:47:10 2019 daemon.info hostapd: wlan0: STA 
a4:xx:xx:xx:6e:0f WPA: pairwise key handshake completed (RSN)
Thu Jan 31 22:47:10 2019 daemon.info dnsmasq-dhcp[3793]: 
DHCPREQUEST(br-lan) 10.0.0.5 a4:xx:xx:xx:6e:0f
Thu Jan 31 22:47:10 2019 daemon.info dnsmasq-dhcp[3793]: 
DHCPACK(br-lan) 10.0.0.5 a4:xx:xx:xx:6e:0f icarus

I looked at the unfiltered log, no mt76 related messages whatsoever, 
just dnsmasq, hostapd and odhcpd messages in there.

Since that hang already happened within the hour, I ran a new build 
with the most recent mt76 bump (2019-01-31) together with the 'disable 
edcca' patch. That has been working fine so far (although I'm not 
hitting 50 MBps anymore :-P ). It's been up since Friday afternoon, so 
almost 30 hours now. The radio gets shut down at night, but I've been 
using it for hours and no issues as far as I can tell.

Do you want me to try the second patch, or is this OK?

Thanks!

Stijn

> 
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel


_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel