Linksys rt3200: radio0 device is not active (mt7622)

Hello,
I am struggling with lastest
openwrt-mediatek-mt7622-linksys_e8450-ubi-squashfs-sysupgrade
on a freshly installed belkin rt3200.
I can't enable radio0 ( on 2ghz freqs), radio1 is working fine.
I am on OpenWrt SNAPSHOT r18125-b764cb9e5b
I tried cleaning configuration and restarting from scratch but I always never manage to enable radio0
I am attaching relevant config and log
can anyone please point me to some hint?
Thanks
A.


config wifi-device 'radio0'
        option type 'mac80211'
        option path 'platform/18000000.wmac'
        option channel '1'
        option band '2g'
        option htmode 'HT20'
        option country 'IT'
        option cell_density '0'

config wifi-device 'radio1'
        option type 'mac80211'
        option path '1a143000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0'
        option channel '36'
        option band '5g'
        option htmode 'HE80'
        option country 'IT'
        option cell_density '0'

----system log----
Sun Dec 26 12:52:20 2021 daemon.notice hostapd: Configuration file: /var/run/hostapd-phy0.conf (phy wlan0) --> new PHY
Sun Dec 26 12:52:20 2021 daemon.err odhcp6c[2205]: Failed to send SOLICIT message to ff02::1:2 (Address not available)
Sun Dec 26 12:52:20 2021 daemon.err odhcpd[1873]: Failed to send to ff02::1%lan@br-lan (Address not available)
Sun Dec 26 12:52:36 2021 daemon.err odhcpd[1873]: Failed to send to ff02::1%lan@br-lan (Address not available)
Sun Dec 26 12:52:37 2021 kern.err kernel: [   29.325397] mt7622-wmac 18000000.wmac: Message 80000010 (seq 1) timeout
Sun Dec 26 12:52:37 2021 kern.err kernel: [   29.332016] mt7622-wmac 18000000.wmac: Failed to get patch semaphore
Sun Dec 26 12:52:37 2021 kern.err kernel: [   29.555667] mt7622-wmac 18000000.wmac: Failed to get patch semaphore
Sun Dec 26 12:52:37 2021 kern.err kernel: [   29.775623] mt7622-wmac 18000000.wmac: Failed to get patch semaphore
Sun Dec 26 12:52:37 2021 kern.err kernel: [   29.995627] mt7622-wmac 18000000.wmac: Failed to get patch semaphore
Sun Dec 26 12:52:37 2021 kern.err kernel: [   30.215620] mt7622-wmac 18000000.wmac: Failed to get patch semaphore
Sun Dec 26 12:52:38 2021 kern.err kernel: [   30.435634] mt7622-wmac 18000000.wmac: Failed to get patch semaphore
Sun Dec 26 12:52:38 2021 kern.err kernel: [   30.655616] mt7622-wmac 18000000.wmac: Failed to get patch semaphore
Sun Dec 26 12:52:38 2021 kern.err kernel: [   30.875621] mt7622-wmac 18000000.wmac: Failed to get patch semaphore
Sun Dec 26 12:52:38 2021 kern.err kernel: [   31.095632] mt7622-wmac 18000000.wmac: Failed to get patch semaphore
Sun Dec 26 12:52:38 2021 kern.err kernel: [   31.315639] mt7622-wmac 18000000.wmac: Failed to get patch semaphore
Sun Dec 26 12:52:39 2021 daemon.err hostapd: Could not set interface wlan0 flags (UP): I/O error
Sun Dec 26 12:52:39 2021 daemon.err hostapd: nl80211: Could not set interface 'wlan0' UP
Sun Dec 26 12:52:39 2021 daemon.notice hostapd: nl80211: deinit ifname=wlan0 disabled_11b_rates=0
Sun Dec 26 12:52:39 2021 daemon.err hostapd: nl80211 driver initialization failed.
Sun Dec 26 12:52:39 2021 daemon.notice hostapd: wlan0: CTRL-EVENT-TERMINATING
Sun Dec 26 12:52:39 2021 daemon.err hostapd: hostapd_free_hapd_data: Interface wlan0 wasn't started
Sun Dec 26 12:52:39 2021 daemon.err odhcp6c[2205]: Failed to send RS (Address not available)
Sun Dec 26 12:52:39 2021 kern.err kernel: [   31.535622] mt7622-wmac 18000000.wmac: Failed to get patch semaphore
------ /var/run/hostapd-phy0.conf----------
driver=nl80211
logger_syslog=127
logger_syslog_level=2
logger_stdout=127
logger_stdout_level=2
country_code=IT
ieee80211d=1
hw_mode=g
supported_rates=60 90 120 180 240 360 480 540
basic_rates=60 120 240
beacon_int=100
dtim_period=2
channel=1
chanlist=1


ieee80211n=1
ht_coex=0
ht_capab=[LDPC][SHORT-GI-20][SHORT-GI-40][TX-STBC][RX-STBC1]

radio_config_id=644f1e4d25de0d4218d6867f8f2ea976
interface=wlan0
ctrl_interface=/var/run/hostapd
ap_isolate=1
bss_load_update_period=60
chan_util_avg_period=600
disassoc_low_ack=1
skip_inactivity_poll=0
preamble=1
wmm_enabled=1
ignore_broadcast_ssid=0
uapsd_advertisement_enabled=1
utf8_ssid=1
multi_ap=0
wpa_passphrase=xxxxxx
wpa_psk_file=/var/run/hostapd-wlan0.psk
auth_algs=1
wpa=2
wpa_pairwise=CCMP
ssid=myssid
bridge=br-lan
wds_bridge=
snoop_iface=br-lan
wpa_disable_eapol_key_retries=0
wpa_key_mgmt=WPA-PSK
okc=0
disable_pmksa_caching=1
dynamic_vlan=0
vlan_naming=1
vlan_no_bridge=1
vlan_file=/var/run/hostapd-wlan0.vlan
qos_map_set=0,0,2,16,1,1,255,255,18,22,24,38,40,40,44,46,48,56
config_id=61b8fc1289c27f0698f45495ba17f3c7
bssid=e8:9f:80:d5:d8:
1 Like

Oh, that looks weird. Please check if the firmware files /lib/firmware/mediatek/mt7622_rom_patch.bin and /lib/firmware/mediatek/mt7622_n9.bin are in place (why ever they should be missing?).
Next step is to check for EEPROM data in hexdump -C /dev/mtd2 which should start with

00000000  22 76 .. ..

If both are present and you are using an official build, I'm afraid the hardware has a problem (which may even be something as odd as the power supply being too weak).

2 Likes

Hi,
thanks for your answer
everything looks in place:

root@GolemWRT6:~# ls -al /lib/firmware/mediatek/mt7622_rom_patch.bin
-rw-r--r--    1 root     root         82110 Dec 24 23:15 /lib/firmware/mediatek/mt7622_rom_patch.bin

root@GolemWRT6:~# ls -al /lib/firmware/mediatek/mt7622_n9.bin
-rw-r--r--    1 root     root        300072 Dec 24 23:15 /lib/firmware/mediatek/mt7622_n9.bin

hexdump -C /dev/mtd2

00000000  22 76 02 00 e8 9f 80 d5  d8 04 00 00 00 00 00 00  |"v..............|
00000000  22 76 02 00 e8 9f 80 d5  d8 04 00 00 00 00 00 00  |"v..............|
00000010  83 55 4b 00 00 00 00 00  00 00 00 00 00 00 00 00  |.UK.............|
...

please note that I tested the router before flashing and with the stock belkin firmware the 2ghz radio was working.

I will try moving the power supply thanks

happy holidays
A.

8(
even changing the socket always gives me

Mon Dec 27 09:11:50 2021 kern.err kernel: [   29.325846] mt7622-wmac 18000000.wmac: Message 80000010 (seq 1) timeout
Mon Dec 27 09:11:50 2021 kern.err kernel: [   29.332463] mt7622-wmac 18000000.wmac: Failed to get patch semaphore
Mon Dec 27 09:11:50 2021 daemon.err odhcpd[1876]: Failed to send to ff02::1%lan@br-lan (Address not available)
Mon Dec 27 09:11:51 2021 kern.err kernel: [   29.556113] mt7622-wmac 18000000.wmac: Failed to get patch semaphore
Mon Dec 27 09:11:51 2021 kern.err kernel: [   29.776094] mt7622-wmac 18000000.wmac: Failed to get patch semaphore
Mon Dec 27 09:11:51 2021 kern.err kernel: [   29.996086] mt7622-wmac 18000000.wmac: Failed to get patch semaphore
Mon Dec 27 09:11:51 2021 kern.err kernel: [   30.216080] mt7622-wmac 18000000.wmac: Failed to get patch semaphore
Mon Dec 27 09:11:51 2021 kern.err kernel: [   30.436084] mt7622-wmac 18000000.wmac: Failed to get patch semaphore
Mon Dec 27 09:11:52 2021 kern.err kernel: [   30.656059] mt7622-wmac 18000000.wmac: Failed to get patch semaphore
Mon Dec 27 09:11:52 2021 kern.err kernel: [   30.876071] mt7622-wmac 18000000.wmac: Failed to get patch semaphore
Mon Dec 27 09:11:52 2021 kern.err kernel: [   31.096070] mt7622-wmac 18000000.wmac: Failed to get patch semaphore
Mon Dec 27 09:11:52 2021 kern.err kernel: [   31.316080] mt7622-wmac 18000000.wmac: Failed to get patch semaphore
Mon Dec 27 09:11:52 2021 daemon.err hostapd: Could not set interface wlan0 flags (UP): I/O error

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?

2 Likes

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.

1 Like

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.

2 Likes

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.)

1 Like

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:

  1. Did you enable CPU frequency scaling?
  2. Which channel, tx-power and country did you set for 2.4 GHz WiFi?
  3. Are you using HT40 or HT20 configuration?
2 Likes

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.

  1. I did enable frequency scaling from the start, and still have it enabled.
  2. 2.4GHz config: Channel is 6, tx-power is default, country is U.S.
  3. 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?

1 Like

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.

3 Likes

@FanOfOpenWRT @daniel is the developer whose images you have been using. Dangowrt is his GitHub handle I believe.

2 Likes

Oh. My. GOD. :heart_eyes: 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!

1 Like

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)

3 Likes

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).

3 Likes

@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.

2 Likes

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?

1 Like

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)

3 Likes
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.

1 Like

@Ansuel said this about schedutil:

#1

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...)

#2

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.

2 Likes