Did you applied any fixes to the build 19.07.5 ? How stable was 2.4Ghz wireless?
I did not apply any fixes to the 19.07.5. version. The 2.4Ghz, for me, is stable, but the range is not very good as it was with the revised V2.06 load with the Candela fix.
NoTengoBattery suggested setting panic_on_oops value to zero, but the 19.07.5 version that I am running has the panic_on_oops value set to 1 and I have had no random reboots in almost 53 hours of uptime. I am confused as to why panic_on_oops must be set to zero for kernel versions 5.4.xx, but should be set to a value of 1 for kernel version 4.14.209? I want to run 19.07.5 for a few more days to be certain of no more random reboots.
Because I need the logs to fix this, everybody says that this does not work, but nobody wants to help with their logs.
The idea is to allow the kernel to keep running when the oops happens. opps are not deadly problems (most of the time) unless you are running a kernel with panic_on_oops set to 1; that's why panic_on_oops set to 0 will allow the device not to reboot and gather more information about the running kernel when the oops happens to see it's side effects, dump symbols, check what the device doing when it happened, etc...
Of course, it isn't beneficial if nobody is willing to help me to fix this. Why does this crash happen? I don't know. I know that it was a generalized problem, but for me, it no longer crashes. It may be a conflictive configuration or noise in the electric line. I don't know, and I can not know if nobody wants to share the logs.
What was the point of enabling pstore and creating a wonderful script to recollect the logs, making it 0 worries a piece of cake; when nobody wants to share them? I wonder if I am asking too much. Tell me, because I don't think that asking for basic debug information is an impossible challenge.
At this point won't matter. I won't touch this until February because of my users' lack of help. I focus on studying rather than guessing the problem without a single line of logs or otherwise useful information.
Happy new year to everyone. Enjoy your new year, and I hope is better for all of you. See you in February.
3 Likes
I understand and I agree. I decided not to run 19.07.5 any further than 55 hours. I have now loaded your new V2.06 plus Candela.tar.gz and I set the value of panic_on_oops to 0 instead of 1. It has been running now continuously for 13-1/2 hours with 12 to 15 connections. I see that some data has already been collected in the bootfs/pstore folder but nothing yet in the /sys/fs/pstore folder.
OK, the router rebooted itself after an uptime of 16 hours running V2.06 and with the value of panic_on_oops set to 0. When the router came back up (rebooted) the panic_on_oops value had defaulted to 1. I will need to remove the router for a while and reinstall the Netgear as the wife has to do some important work and needs a stable network.
Good afternoon, greetings from Venezuela, I have an ea6350 v3 router, I just installed the Custom ROM v2.06 version and I'm doing great, it's very stable and the 2.4 Mhz wifi network is going great and it's much more stable than the official version 19.07. 5, thank you for sharing your experiences.
I'm new to this topic also from openwrt, I have some questions, is there a way to translate the Spanish version ????? In case you want to go back to the stock version, I just do it by updating the official version?
Thank you
If you are running V2.06 FW and you want to reboot to the Linksys FW. From the dashboard click on system, then click on advanced reboot, then click on Reboot to alternate partition. The router will then reboot to the partition with Linksys FW.
1 Like
Hello, I have an EA8300, and the newest version 2.10 (for the most part) fixed 5ghz signals but I'm getting really low speeds on 2.4ghz nevertheless, awesome build. it's pretty stable most of the time.
Good evening I installed v2.10 on my EA 6350 V3, and so far it is going great, very stable, congratulations to the creator.
However, it is normal that with the 2.4 mhz wifi network it has this average speed Bitrate: 25.2 Mbit / s ???
Thank you.
Hello, I'm not sure but i read something about -ct driver being the cause. You could try the non-ct firmware if you want.
My ezviz after some tweak works like a charm, no problems at all, but it work as a simple ap, now i have new ap and i can switch to normal router for guests and do more testing stability. Thanks for build op
do ipq40xx have hw offload for nat etc ?
Hello @NoTengoBattery, I hope you and your family are well.
I am trying these days the last version (2.10) and the Wireless thing is working well (at least is ok).. but I am suffering of random reboots of the router like others users here.
I will share to you the logs in the next random reboot. I performed the oops command to 0, so we will have logs ready in the next random reboot.
Hope it helps with your great work!
I also encourage the rest to do the same 
Hello @NoTengoBattery. I've sent to your mail the crash dump as you request. Hope it helps.
Edit: I forget to tell you that I've disabled all radios and the crash still happens.
I've been experiencing random reboots since I moved to this firmware a while ago. Don't know whether it's specific for this custom build, or to the OpenWRT base altogether, but I've never encounter random reboot on the stock firmware. Not a single time. With this, it happens stably every 1-2 days. Nevertheless, the benefits of this firmware over the stock are too significant, so I just endure the problem...
On EA6350, usb randomly failes when connecting/disconnecting my android phone(RNDIS)
Fri Feb 5 19:08:11 2021 kern.info kernel: [ 188.327113] usb 1-1: USB disconnect, device number 2
Fri Feb 5 19:08:16 2021 kern.warn kernel: [ 193.370283] xhci-hcd xhci-hcd.0.auto: xHCI host not responding to stop endpoint command.
Fri Feb 5 19:08:16 2021 kern.warn kernel: [ 193.386595] xhci-hcd xhci-hcd.0.auto: Host halt failed, -110
Fri Feb 5 19:08:16 2021 kern.err kernel: [ 193.386755] xhci-hcd xhci-hcd.0.auto: xHCI host controller not responding, assume dead
Fri Feb 5 19:08:16 2021 kern.err kernel: [ 193.391783] xhci-hcd xhci-hcd.0.auto: HC died; cleaning up
I worked around it with this hotplug script, if anyone else hits this issue.
cat << "EOF" > /etc/hotplug.d/usb/99-usbbugfix
[ "${ACTION}" = "offline" ] && {
logger -t hotplug "*** USB BUG WORKAROUND ***" && rmmod xhci_plat_hcd && modprobe xhci_plat_hcd
}
EOF
Over the last few months I have run several of the V1.XX and V2.XX FW's and I have suffered random reboots on all of them. Now, for the last month I have been running various Openwrt snapshots on my EA6350V3 and they have been very stable and I no longer experience random reboots. The downside of snapshots is that I have to load Luci and other packages on my own.
I really like notengobattery's versions because they already contain Luci and most of the packages that I need and some other nice features as well. I hope that he soon will be able to solve the random reboot problem.
1 Like
Hi @NoTengoBattery
Can you add support for Gl-iNet GL-B1300?
Thanks
EDIT: Just noticed that B1300 is WiP.
What is the progress on it?
Hi, thank you for your work
I have installed this firmware to use my Linksys EA6350v3 (Civic) with the new FTTH connection, now the router is connected to a switch and than to the ONT
I have experienced the randomly reboot
today, like you written in this thread, I changed the panic_on_oops to 0
so if you need I can collect the necessary logs for you
So this build sort of works on the MR9000 as well. It detects the switch but there is an error that is occurring and I am currently investigating what exactly that issue is. I am wondering what the major differences are between the MR9000 vs EA/MR8300 as only two of the three radios are populated as well. More to come.