MichaIng

Strange only that pre-5.4 the same large clocks jump was never an issue and with only lowest and highest clocks as only two pstates the jump was always the largest...

May I express the urgency I see in resolving or working around this bug? This has the potential to destroy systems by causing file corruption in unconditionally crashed services, e.g....

And remember that this is only a workaround for user which are not yet aware of the issue. In your case you simply `arm_freq_min` to value of 600 or higher...

> So If i just comment out my arm_freq_min=300, it will go to the default 600 right? Yes exactly. On RPi1+Zero it's 700 Mhz but all defaults work fine.

Subscribe to this issue, I'm sure we'll get a dev notice once a real fix is merged and I'll anyway keep an eye on it as well and search through...

Jep seems to work fine. Just tested on RPi2 with `arm_freq_min=150` which enables a lowest pstate of 200 MHz and all states are used, no hang or crash until now:...

Yes, `rpi-update` by default loads the current [master branch](https://github.com/raspberrypi/firmware/tree/master), compared to the [stable branch](https://github.com/raspberrypi/firmware/tree/stable) that matches the apt packages. It would be great if you could test it as well,...

No, only a single commit has been merged that has nothing to do with this issue: https://github.com/raspberrypi/firmware/commit/2b41f509710d99758a5b8efa88d95dd0e9169c0a Must have been an urgent one as well to justify a full firmware...

Okay not sure if it is related, but with newest kernel I get another hang/crash: dmesg ``` [ 407.680929] rcu: INFO: rcu_sched self-detected stall on CPU [ 407.680961] rcu: 3-....:...

Very latest kernel/firmware, to test the [initial_turbo+performance](https://github.com/raspberrypi/firmware/issues/1469) governor solution. Just reverted min frequencies to defaults, booted with performance governor, which gives 900 MHz (RPi2) now reliable with `initial_turbo`, then switched...