[FS#3099] ipq806x: kernel 5.4 crash related to CPU frequency scaling

[OpenWrt Bugs]

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.

The following task has a new comment added:

FS#3099 - ipq806x: kernel 5.4 crash related to CPU frequency scaling
User who did this - Shane (digitalcircuit)

----------
I appear to be running into this bug with 21.02.0-rc1 on the ZyXEL NBG6817, [[https://bugs.openwrt.org/index.php?do=details&task_id=2053#comment9664|as noted on a follow-up to the WiFi firmware bug seemingly being fixed]].

I have a bursty CPU workload (backing up via Deja Dup to separate OpenSSH SFTP chroot, which cycles between local PC compress/encrypt, low router CPU use, and SFTP upload of 25 MB files, moderate router CPU use), which triggers a panic and reboot within about 1-8 hours.  Switching to the "performance" governor has finally allowed a full backup to complete successfully.

Continuous high CPU and network usage [[https://bugs.openwrt.org/index.php?do=details&task_id=804#comment3171|via iperf3 and OpenSSL benchmark as suggested by a past bug report]] does not seem to trigger this issue as quickly as that bug report suggested it should (tried 40 minutes, willing to try longer if desired).

Most panics do not show anything being sent to a UDP rsyslog listener on the wired network; the only kernel panic I've caught so far was an "rcu_sched" hang on one CPU core, so I imagine I'll need to either compile a custom kernel for ramoops support, or solder on serial headers inside the router.

My next goal was to devise a script that alternatively pegs the CPU for 1-5 seconds then let it rest for 1-5 seconds to exercise the CPU frequency governor.  If I can reliably reproduce the issue, then I'll try the snapshot - though if others are able to test this sooner, please don't wait for me!  (This is my primary home Internet router so it's a bit difficult to schedule experiments with it.)
----------

More information can be found at the following URL:
https://bugs.openwrt.org/index.php?do=details&task_id=3099#comment9674

You are receiving this message because you have requested it from the Flyspray bugtracking system.  If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.