Looking for Feedback: RT-BE92U stability issues

[dinko05]

I am on 3006.102.5 (so a version prior to the latest GPL updates). I had tried 3006.102.6 when it came out but it was *so* unstable for me that I went back to 102.5.

On that version it is *mostly* stable. I still have a programmed reboot every night and I have a cron job that monitors for clock discrepancies and reboots if detected and *mostly*, it is stable.

Sometimes, however, it does crash. I finally got around to setting up remote logging and here are the excerpts of the latest two crashes. They are typically similar like this. I have not figured out what triggers them. Like I said, it can be stable for weeks and then, in a day, it just reboots a few times like this.

I can try 102.7 at some point if that is helpful. 102.6 was just TOO unstable and it would crash multiple times a day and since 102.7 seems to use the same kernel, I didn't both with it yet.

```
Feb 26 12:55:19 router kernel: [BLOCKED - INBOUND] IN=vlan4094 OUT= MAC=XXX SRC=XXX DST=XXX LEN=60 TOS=0x00 PREC=0x00 TTL=43 ID=31098 DF PROTO=TCP SPT=53570 DPT=7015 SEQ=37579354
9 ACK=0 WINDOW=5840 RES=0x00 SYN URGP=0 OPT (020405B4080A4445414400000000030301040200)
Sep 12 14:57:21 router chronyd[10486]: Forward time jump detected!
Aug 7 08:29:05 router kernel: rcu: INFO: rcu_preempt self-detected stall on CPU
Aug 7 08:29:05 router kernel: rcu: INFO: rcu_sched detected stalls on CPUs/tasks:
Aug 7 08:29:05 router kernel: rcu: INFO: rcu_bh detected stalls on CPUs/tasks:
Aug 7 08:29:05 router kernel: rcu: 1-...!: (16 ticks this GP) idle=0da/0/0x1 softirq=5235988/5235996 fqs=0
Aug 7 08:29:05 router kernel: rcu: (detected by 3, t=900726558046 jiffies, g=2448077, q=1360)
Aug 7 08:29:05 router kernel: Task dump for CPU 1:
Aug 7 08:29:05 router kernel: swapper/1 R running task 0 0 1 0x0000000a
Aug 7 08:29:05 router kernel: Call trace:
Aug 7 08:29:05 router kernel: __switch_to+0xe8/0x170
Aug 7 08:29:05 router kernel: 0xffffff800809bef0
Aug 7 08:29:05 router kernel: rcu: rcu_sched kthread starved for 900726558046 jiffies! g2448077 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402 ->cpu=0
Aug 7 08:29:05 router kernel: rcu: RCU grace-period kthread stack dump:
Aug 7 08:29:05 router kernel: rcu_sched I 0 11 2 0x00000008
Aug 7 08:29:05 router kernel: Call trace:
Aug 7 08:29:05 router kernel: __switch_to+0xe8/0x170
Aug 7 08:29:05 router kernel: __schedule+0x214/0x5a0
Aug 7 08:29:05 router kernel: schedule+0x38/0xa0
Aug 7 08:29:05 router kernel: schedule_timeout+0x15c/0x2a0
Aug 7 08:29:05 router kernel: rcu_gp_kthread+0x488/0x900
Aug 7 08:29:05 router kernel: kthread+0x118/0x150
Aug 7 08:29:05 router kernel: ret_from_fork+0x10/0x24
Aug 7 08:29:05 router kernel: rcu: 1-...!: (2 ticks this GP) idle=0da/0/0x1 softirq=5235996/5235996 fqs=0
Aug 7 08:29:05 router kernel: rcu: 1-...!: (7822 ticks this GP) idle=0da/0/0x1 softirq=5228421/5235996 fqs=1
Aug 7 08:29:05 router kernel: rcu: (t=900726558053 jiffies g=6702293 q=32270)
Aug 7 08:29:05 router kernel: rcu: (detected by 0, t=900726558058 jiffies, g=-255, q=1)
Aug 7 08:29:05 router kernel: Task dump for CPU 1:
Aug 7 08:29:05 router kernel: Task dump for CPU 1:
Aug 7 08:29:05 router kernel: swapper/1 R running task 0 0 1 0x0000000a
Aug 7 08:29:05 router kernel: swapper/1 R running task 0 0 1 0x0000000a
Aug 7 08:29:05 router kernel: Call trace:
Aug 7 08:29:05 router kernel: Call trace:
Aug 7 08:29:05 router kernel: dump_backtrace+0x0/0x150
Aug 7 08:29:05 router kernel: __switch_to+0xe8/0x170
Aug 7 08:29:05 router kernel: show_stack+0x14/0x20
Aug 7 08:29:05 router kernel: 0xffffff800809bef0
Aug 7 08:29:05 router kernel: sched_show_task+0x100/0x120
Aug 7 08:29:05 router kernel: dump_cpu_task+0x40/0x4c
Aug 7 08:29:05 router kernel: rcu_dump_cpu_stacks+0x90/0xcc
Aug 7 08:29:05 router kernel: rcu_check_callbacks+0x67c/0x810
Aug 7 08:29:05 router kernel: update_process_times+0x2c/0x70
Aug 7 08:29:05 router kernel: tick_sched_timer+0x54/0xd0
Aug 7 08:29:05 router kernel: __hrtimer_run_queues+0x13c/0x1d0
Aug 7 08:29:05 router kernel: hrtimer_interrupt+0xe4/0x2b0
Aug 7 08:29:05 router kernel: arch_timer_handler_phys+0x30/0x40
Aug 7 08:29:05 router kernel: handle_percpu_devid_irq+0x80/0x140
Aug 7 08:29:05 router kernel: __handle_domain_irq+0x70/0xd0
Aug 7 08:29:05 router kernel: gic_handle_irq+0x5c/0xc0
Aug 7 08:29:05 router kernel: el1_irq+0xe8/0x190
Aug 7 08:29:05 router kernel: cpuidle_enter_state+0x80/0x220
Aug 7 08:29:05 router kernel: cpuidle_enter+0x18/0x20
Aug 7 08:29:05 router kernel: do_idle+0x1d8/0x260
Aug 7 08:29:05 router kernel: cpu_startup_entry+0x20/0x40
Aug 7 08:29:05 router kernel: secondary_start_kernel+0x13c/0x170
Aug 7 08:29:05 router crond[4736]: time disparity of 15012122 minutes detected
Aug 7 08:29:05 router kernel: tdts_core_ioctl_udb_op_prog_ctrl() fail!
```

I attached another one in a file. FOr that one there are two stalls very close to one another. The first one seems to be OK and then the second one kills it.

On reboot, it does seem to print out information too (that it doesn't print on a regular reboot). I attached one such output.



Thanks!
Romain

 

[killweav]

There is a HW v6.0 now. Have an RMA w/ASUS for my v3.0 and went ahead and got this one. I'm sure I can find some use for my v3 once it comes back (radio self-interference). About to set this up and test it with iPerf3 to ensure the interference is gone. (Merlin v. 3006.102.7 beta_2).

 

[GJJ]

There is a HW v6.0 now. Have an RMA w/ASUS for my v3.0 and went ahead and got this one. I'm sure I can find some use for my v3 once it comes back (radio self-interference). About to set this up and test it with iPerf3 to ensure the interference is gone. (Merlin v. 3006.102.7 beta_2).

Nothing to do with this topic, but just be careful when covering up your barcodes, that you do a good job. There's enough of the bottom barcode showing to make it readable without any work, while the top barcode and the 2D barcode could probably be reconstructed with a small amount of effort. Cover as much if not all of a 2D barcode as possible, as they include error correction and dependant on encoding, can be read with a fair chunk missing.

Sorry, just being paranoid and in this case, I think you don't have anything to worry about, but some one out there might.

GJ

 

[jamesnmandy]

9.0.0.6_102_39065 ?

After testing it, make sure you submit your logs through the Feedback page if you still experience issues or crashes.

I haven't flashed it yet. I'm still running the same configuration as when I had issues but I did add a ethernet connected LAN rpi/pihole and turned off MLO in the router. So far there have been zero issues like before. It seems as if simply turning off MLO made the connection issues during "heavy load" go away on the latest stock Asus firmware. I'm gonna run it this way at least a few more days and then I will flash the beta firmware Asus sent me and turn on MLO and see if it still has issues under similar load.

 

[Ev0]

Sorry only just found this thread.

So 3006.102.6 release introduced a bug for me, where after approx 1 week of being online, the router would drop the connection randomly throughout the day / night, this would require me to either reboot the router or to set the connection to off and back on again, however doing the 2nd option it would only drop out again a few hours later.

The workaround was to set the be92u to reboot once a day (early hours in the morning) and this seemed to work fine.

3006.102.7_beta1 fixed this issue for me, I was able to remove the daily reboot, and the router remained stable for the few weeks I was using this fw version.

I updated to 3006.102.7_beta2 and the connection dropout issue returned, exactly as it was in 3006.102.6 release.

I have now reverted to 3006.102.7_beta1 and it's once again been stable for me for over a week now.

Internet connection drop out affects both lan and wifi.

 

[jzchen]

Not to be picking on anyone in particular but I believe he's looking for feedback on ASUSwrt firmware, not his Merlin version...

 

[bennor]

A reminder of what RMerlin is looking for in this discussion on the RT-BE92U:

I'm trying to gather more info/feedback from RT-BE92U owners who are suffering from major performance issues, or general instability or crashes.

If you are experiencing issues, please test again using the latest stock firmware (if you were using Asuswrt-Merlin). If you can still reproduce the issues, then please report them back here so I can forward the feedback to Asus, as at this point there doesn't seem to be any internal info hinting at widespread issues, which is somewhat surprising. Using the Feedback form on the webui is also a good idea, as it will forward technical details to Asus for further investigation.

 

[Ev0]

Not to be picking on anyone in particular but I believe he's looking for feedback on ASUSwrt firmware, not his Merlin version...

A reminder of what RMerlin is looking for in this discussion on the RT-BE92U:

Yep I get that, however I thought it might be useful to pointout that for me at least I had stability issues with his Merlin 3006.102.6 release that were fixed in 3006.102.7 beta1 and then reintroduced in 3006.102.7 beta2.

He will know exactly what the differences are in those 3 fw versions and it could narrow down where the issues stem from.

 

[RMerlin]

Yep I get that, however I thought it might be useful to pointout that for me at least I had stability issues with his Merlin 3006.102.6 release that were fixed in 3006.102.7 beta1 and then reintroduced in 3006.102.7 beta2.

He will know exactly what the differences are in those 3 fw versions and it could narrow down where the issues stem from.

That's not possible, since beta2 for the RT-BE92U only contains webui changes.

As others pointed out, that thread was to gather feedback specifically on the stock firmware, to determine if the GPL version used in that stock firmware contained the sames issues or different ones.