Pi 3 shutting down-ish

Has there been any progress with this?

No progress from the Pi devs, but Jeffrey did implement a fair few adjustments to the OS once we isolated it down to the mouse pointer. We’ve had no feedback from the register dumps we’ve given the Pi devs although it probably needs someone with authority in ROOL to escalate it.

I managed to workaround the issue by lowering the lower CPU/GPU speed in CONFIG.TXT, although why that fixes it for me is unclear:

arm_freq_min=100
gpu_freq_min=75

The Pi still seems to be working but I need to confirm this

I believe the Pixelvalve in the GPU is shutting down, the CPU will be working fine.

I can’t find a way to reproduce the problem.

I can reproduce the issue at will, so have done most of the testing but without assistance from the Pi devs, we’re not going to resolve the problem unless we find the root cause.

It’s related to the mouse pointer being visible when gamma is enabled, although we’re not sure why. If you turn the mouse pointer off or disable gamma, the issue doesn’t occur. It has all the hallmarks of the Pixelvalve getting overloaded, but its nowhere near capacity unless something is going horribly wrong in the firmware/GPU when the mouse pointer is updated.

Due to another, unrelated bug I was tempted to update firmware and OS on my Raspberry 3B and promptly ran in into this video blanking bug. Gamma disabling and the advanced vodoo of setting the ARM/GPU minimum frequencies to low values didn’t help at all.

In fact the frequency trick made it even worse: The power-on cycle gave me a few seconds of a black screen with a “Not supported” message from the monitor itself, followed by a few seconds of the boot screen and the desktop. The finale was, of course, the final black screen of death, everytime.

That made me thinking (guessing): If low frequencies or changing of the frequency in general trigger this bug, maybe the Rasberry, the monitor and I will be much happier with a fixed frequency.

So I added force_turbo=1 to the config.txt file and restarted. For the next 1 to 2 hours my Raspberry ran without any blanking, most of the time unattended but also with me giving the mouse a good wiggle.

Whatever bug might be lurking deep in the system, it seems to hold a deep dislike for dynamic throttling. Downside is, the main chip get quite warm, so in the long run, I need to invest in some cooling.

If the blanking bug rises his ugly head again, I will report here.

I got a RasPi 3B+ recently. It has started to blank the screen. It’s running “CPUClock”, limiting the CPU temperature to 60C (I’ve just changed the setting to 55C). So we still have the problem.

I read that it’s possible to disable the gamma-faffing to solve the problem, but that means I can’t “just” update the RISC OS image without building it myself. I can do that, but it means that an operation that should be quick and simple is neither.

Naive question: would it be possible to enable or disable the gamma-faffing by configuration, rather than by building?

I should add that this is with RO 5.27 (24-Mar-20) and the latest set of firmware and config files shown in the Documentation section of this site. I have no special configuration.

The last time it blanked, I was able to access it via VNC from a Linux box, but only for a few minutes; after that I decided that I had to power cycle it.

Naive question: would it be possible to enable or disable the gamma-faffing by configuration, rather than by building?

Yes: There’s a disable_gamma option you can add to cmdline.txt

https://www.riscosopen.org/wiki/documentation/show/cmdline.txt%20(Raspberry%20Pi)

The 5.27 ROM build from the 22-Mar-20 hasn’t so far blanked on my Pi3B and its been on all day. However the following build from 24-Mar-20 does regularly.

Was gamma disabled in the 22-Mar-20 build?

Once again: thank you, Jeffrey!

Applied. So far, so good…

It made me think some more about what’s going wrong. We know that some specimens are more affected than others. We know that MOS gets slower at higher temperatures, and we think that temperature may have some influence on the chances of the problem showing up. We know that Linux on the same chip doesn’t show the problem. So is it possible that it’s not what we send across the CPU-GPU interface, but rather the timing with which we send it? Is there some mechanism to change the access speed or time, that we are either not using or are using differently from Linux?

I wonder if Theo could tell us?

The issue isn’t the gamma, I believe we tracked it down to PixelValve shutting down most probably relating to a timing issue. The difference between Linux and RISCOS is the use of VCHIQ for the hardware pointer within RISCOS, instead of using the Set Cursor Info mailbox.

I believe the issue was left with us to try switching RISCOS to use the mailbox for the pointer, although I’m not sure if that was implemented.

Jeffrey and I did a lot of investigating into the issue for the Pi devs, but its been over a year since we’ve looked into it any further as we’ve been waiting for their feedback on the register dumps we provided.

Thank you for the update and clarification.

My Pi3B has been running all day. Until I decided a few moments ago to logon and write this. I clicked into the e-mail address field of the logon screen. Screen blanked. You just couldn’t make it up!