I was about to suggest that to you, but good that you managed yourself. Let me explain what happened:
By flashing the non-UBI build, the OS then could not find its root filesystem and would crash during boot.
When ever the OS crashes the details are recorded in RAM (pstore/ramoops) and the device reboots. At the next boot the bootloader checks that place in RAM and finds the recorded data of the crash, which triggers it to boot into recovery mode. You have then probably already rectified your mistake and flashed the UBI build of 22.03.5, however, the data of the recorded crash persisted in RAM until you turned off the router.
Wondering if anyone is experiencing router hang with the latest master builds? My E8450 hung twice, roughly 1 week apart. Happened again an hour ago. This time, I access the serial console to check what's wrong. Although the router is running, it appears that mt7915e driver hung.
"ifconfig" resulted in mt7915e reporting timeouts.
My E8450 is running my own master build from two weeks ago, if it makes any difference. Hardware offload and "wed" are enabled, with bridge vlan filtering.
Previous builds works great. Looks like the latest mt76/mt7915e driver has introduced issues?
Edit: Ethernet doesn't work as well when this happens. Forgot to look at dmesg output as I needed to get the network up and running fast.
Turns out I may not be the first and this issue may have been simmering for a while for mt7915e. Been reading Github issues for openwrt/mt76 and what was discussed seem like what I'm seeing from the serial console log.
My older builds seems stable, so now considering whether to revert back. Let see if I will encounter the issue for the third time.
I had thought this is due to my openclash ipk...Certainly felt 22.03.5 is not as smooth as 22.03.4 due to this experience. OR my experience could be irrelevant, since I wouldn't know how to produce the logs, etc. But really, the openclash thingy seems to disconnect every now and then on its own under 22.03.5
Sorry for the delay. I had to turn off twice. Can't remember what I did exactly. But i was fretting and spent several hours on this upgrade. I will watch out for build 22.03.6 next time. Wish the Openclash ipk can be part of the attended sysupgrade, but I guess it would never make the cut. Just in case people wonder what openclash is. Please refer to https://github.com/vernesong/OpenClash/releases. Many thanks again. Other than openclash subscription seems to have disconnected on its own under 22.03.5 every now and then, I guess 22.03.5 is better than .4.
Is anyone seeing this in 22.03.5? I have an E8450 set up as a dumb AP using WDS to connect to another E8450.
Tue May 9 22:06:54 2023 kern.info kernel: [854000.783876] mt7530 mdio-bus:00 lan1: Link is Down
Tue May 9 22:06:54 2023 kern.info kernel: [854000.789065] br-lan: port 1(lan1) entered disabled state
Tue May 9 22:06:54 2023 daemon.notice netifd: Network device 'lan1' link is down
Tue May 9 22:06:58 2023 kern.info kernel: [854004.060999] mt7530 mdio-bus:00 lan1: Link is Up - 1Gbps/Full - flow control rx/tx
Tue May 9 22:06:58 2023 kern.info kernel: [854004.068691] br-lan: port 1(lan1) entered blocking state
Tue May 9 22:06:58 2023 kern.info kernel: [854004.074068] br-lan: port 1(lan1) entered forwarding state
Tue May 9 22:06:58 2023 daemon.notice netifd: Network device 'lan1' link is up
I see the link down messages too for my E8450, but that's because my TV is connected to it, and I see this when it is in standby mode. My TV seems to wake up periodically and sleep again. I see the link up/down messages in system log.
When you see these logs in your router, do you know if the device connected to that LAN port is down or up?
AFAIK E8450 do not bring down any ports. It only senses whether the other end connected to its port is up or down. When it boots, OpenWrt will bring up all ports as configured by user. After that it doesn't actively managed the ports.
Do you see any weird behaviour (e.g. no traffic flowing) for your router?
I can also confirm that latest master builds are causing the wireless interfaces to become inaccessible after a while. Sometimes very soon after updating the firmware, but sometimes after several days of continuous working without issues. The device is used as a classic router (PPPoE WAN connection) but I am using only wireless devices so I enabled WED. After the latest event I was able to connect to the Ethernet interface and downloaded the log:
Latest messages are during my Ethernet connection for debugging the router, but I left them to see the subsequent timeouts.
I also remember that I've tested a more recent mt76 build than the one used until yesterday by openwrt and noticed that WED was not active. I saw now that they recently updated the mt76 build, will test soon.
Well, my E8450 is happily purring away for more than 10 days now. I've setup a cronjob to detect issues and force a kernel panic so that I can capture the kernel logs. Will know if mine is the same as yours once I get my hands on the logs.
Oh no, my fears were confirmed, with latest mt76 wed is not working, router goes up to 85% CPU usage and the wireless client download speed is lower than before, not even reaching 700Mbps... I have several entries listed in /sys/kernel/debug/ppe0/entries but /sys/kernel/debug/ppe0/bind is empty. What a disappointment
Good news, I've found the cause, this commit: wifi: mt76: mt7915 add tc offloading support. After reverting the changes, wed is back: 30% CPU usage at over 800Mbps. Here is the reverting patch if needed:
Save the text as something like 120-revert-mt7915-add-tc-offloading-support.patch in /package/kernel/mt76/patches and recompile. @nbd Dear Felix, please look at your commit mentioned here, because it breaks wed acceleration on RT3200/E8450. Thanks!
