Hi, I'm having exactly the same problem was trying the version 22.03.2. But when i got back to the original belkin firmware, the 2,4GHz radio works fine, same as the 5GHz one. Any idea what that could be?
Just installed 22.03.3 onto a brand new Belkin RT3200 and the 2.4Ghz worked for a while but now has the exact same problem as @diigii and @abe01 (the 5Ghz network is running smoothly).
Edit: The fix for me was to remove the CPU governor setting from local startup, and also use 20Mhz for the 2.4Ghz radio. Works fine now.
I wasn't able to find the solution for the problem and get rid of this router. But please post the solution if you'll find one.
Yikes, that is very disheartening to hear.
I already gave my perfectly working WiFi 5 router, bought in 2019, to my mom for her house and have had to refurbish a 12-year-old Linksys E3000 (with FreshTomato firmware) just to get a working 2.4GHz radio in my house.
Hoping the fix is software-based and a future OpenWrt update will fix this! The stock firmware worked, so it seems likely it's an OpenWrt or package driver issue that can be corrected.
(Unfortunately I chose not to keep the stock firmware, and can't go back to it. Fortunately I only spent $67 on the Belkin RT3200.)
I'm reading this and also wonder what happened, because on my devices (which I've been using for more than a year now, frequently updating snapshot builds) the 2.4 GHz radio is working fine up to this day.
Hence I have some questions:
- Did you enable CPU frequency scaling?
- Which channel, tx-power and country did you set for 2.4 GHz WiFi?
- Are you using HT40 or HT20 configuration?
I should tell you that I installed dangowrt's patch on a brand new RT3200 & then installed the image in his instructions first, which I believe was 22.03.2, but possibly .1. After that I immediately updated to 22.03.3. The 2.4GHz radio only works sporadically and I can't determine the conditions that make it work or not work at any given time.
- I did enable frequency scaling from the start, and still have it enabled.
- 2.4GHz config: Channel is 6, tx-power is default, country is U.S.
- HT40.
Here are my log entries.
My plan after working for days on end not making progress was to wait until I heard that this issue was fixed in OpenWrt, or else try to start over with the latest snapshot again from time to time and see for myself if it works.
What's the possibility that I have a malfunctioning unit (even though the 2.4Ghz works occasionally on cold power-up only)? Is there any definitive test to run to see if there's a defect?
I know that I'm repeating myself and nobody wants to hear this: The MT7622 went through MediaTek's QA only running at maximum speed. Hence there is the option that using (out-of-spec!) frequency scaling may have physically damaged your device.
It can of course also be that you are dealing with a unit which is faulty from factory, the symptoms you observe could well be caused by a broken voltage regulator, misbehaving electrolyte capacitor or things like that.
For the record: I've only ever used the 2.4GHz radio in HT20 mode, as I'm living in a dense urban environment, forcing the use of HT40 would not be doing myself (or my neighbors) a favor.
Contact me via PM if you would like to revert to stock for testing, I can share the necessary files with you.
@FanOfOpenWRT @daniel is the developer whose images you have been using. Dangowrt is his GitHub handle I believe.
Oh. My. GOD. You fixed it!
I removed the CPU governor setting from local startup, set the radio to 20 Mhz, rebooted, and 2.4Ghz came up. I was SO elated, but knew it could be a fluke, so I soft rebooted again, and it came up again! I'm going to start using it and see where it takes me. You're an absolute life-saver.
Thank you for creating the conversion tool to make this possible and so easy. Will report back if there are any more problems, but now I wanna update to snapshot again so I can benefit from the newest driver packages!
The interesting part about Daniel's theory about the CPU frequency scaling is that abe01 reported identical errors in Dec 2021, which is 10 months earlier than the ondemand scaling was enabled by default in Oct 2022. (The schedutil governor mentioned by @FanOfOpenWRT is nondefault, but is the successor of ondemand in Linux upstream)
Maybe we should ask the user reporting this issue back in Dec 2021 if they had manually enabled frequency scaling (afaik many users did, despite warning and MediaTek employees confirming the lack of QA in any setting other than maximum speed).
@abe01 Did you?
Yeah, you may well have right, and the scaling really does cause trouble.
But we haven't heard more complaints by now, although 'ondemand' was activated by default already in October 2022. The previous 'userspace' was pretty much a no-op, and the frequency stayed on maximum value until October unless you specifically changed it.
I would have expected more bug reports in the last four months if mt7622 radios would susceptible for locking up due to CPU frequency scaling. That makes me hesitant to immediately accept that theory as the sole reason.
EDIT:
Hmmm.
Actually the stable 22.03 has still userspace (=no-op) as default, so probably a large part of the user population does not use scaling. Only master has ondemand as the default.
Hmmm.
Actually the stable 22.03 has still userspace (=no-op) as default, so probably a large part of the user population does not use scaling. Only master has ondemand as the default.
Just to clarify, I had been using schedutil
as per the old suggestion on the wiki and in various forum posts. Removing the schedutil
setting (that I had added) from local startup fixed my 2.4Ghz radio problem entirely.
I am currently on SNAPSHOT r22036-1a145ccb0a so I'm wondering how ondemand
is different, if that is enabled by default and I'm allegedly using it. How to confirm if I'm indeed using ondemand
?
You can see the values from kernel debug data in /sys/devices.
And you can also manipulated some values: governor in use, max freq, min freq, etc.
this is from RT3200, so slightly different values:
root@router5:~# ls /sys/devices/system/cpu/cpufreq/
policy0 schedutil
root@router5:~# ls /sys/devices/system/cpu/cpufreq/policy0/
affected_cpus scaling_cur_freq
cpuinfo_cur_freq scaling_driver
cpuinfo_max_freq scaling_governor
cpuinfo_min_freq scaling_max_freq
cpuinfo_transition_latency scaling_min_freq
related_cpus scaling_setspeed
scaling_available_frequencies stats
scaling_available_governors
root@router5:~# cat /sys/devices/system/cpu/cpufreq/policy0/scaling_governor
schedutil
root@router5:~# cat /sys/devices/system/cpu/cpufreq/policy0/scaling_available_governors
performance schedutil
root@router5:~# echo performance > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor
root@router5:~# cat /sys/devices/system/cpu/cpufreq/policy0/scaling_governor
performance
I changed the governor in use from schedutil to performance (= always max. freq)
root@OpenWrt:~# cat /sys/devices/system/cpu/cpufreq/policy0/scaling_governor
ondemand
So ondemand
won't break MT7622's 2.4Ghz radio initialization but schedutil
appears to.
@Ansuel said this about schedutil:
problem of schedutil is that it requires correct driver use and stuff to handle bw request and afaik not a lot of target does that... (so this is why in some condition you have worse perf... the driver never say what is the correct amount of work that is currently or will do...)
schedutil is for everything else like normal system and phones.... it's not for router with legacy driver and basic cpuscaling and idle state... as I said to make schedutil works correctly it needs to be aware of the task so one of the reason of ondemand giving better perf than schedutil is the fact that the driver doesn't really comunicate to the system the amount of load that will generate.
Hi,
sorry for late answer
I did not enable scaling.
Still having the issue and I moved to asus RT-AX53U
So far, so good, after removing the schedutil
CPU governor from local startup!
2.4Ghz radio has been running fine.
Do you recommend performance
over ondemand
? Apart from the trivial increase in CPU temp from running in performance
, any other downsides?
That was just an explanation my cpufreq settings manipulation example in that same message.
I have been happily using ondemand in my dumb AP RT3200 (that does not use SQM).
But I have noticed (or at least suspected) that cake qdisc in SQM may suffer from changing CPU frequencies, and do prefer the old simple.qos with fq_codel instead of cake.
See discussion in Increase in download bufferbloat with SQM enabled - #6 by moeller0