RPi 4B with RISC-OS 5.28 & 5.29 Lockups

If it’s a Pi we’re talking about, you’ll want to be VERY careful with the big “Loader” file within !Boot. This should never be copied, nor deleted. And I’m not sure I’d move it either.

Moving from an old to a new !Boot is fine, but it must absolutely be a move and not a copy. If it isn’t nothing will appear to go wrong until the reset after you’ve deleted the old !Boot. That card wont then be bootable, so you would need to setup a new SD card with a copy of RISC OS, and recover the data from the old card with a USB card reader.

Daniel, have you ruled out a problem with the hardware?

If you have a spare SD card you could try Raspberry Pi OS and if the lockups still happen it would suggest a hardware issue (rather than a problem with RISC OS).

I had a bad power cable causing serious issues on my Pi so that’s something to check as well as the power supply.

doesn’t spamming the Escape key at boot do that?

In the same way that throwing a handful of coins onto your motherboard will stop it doing what it was doing.

Actually, Escape rarely does anything useful these days. Even Basic forgets to test for it in places. “Escape is just this key, you know?”

I use an RPi4 for my day-to-day desktop computer running Raspberry Pi OS.

For a long while I was getting random crashes on my RPi4. After much ado, I eventually found that the random crashes were being caused by some fault on one of my ‘official’ USB-C RPi4 power supplies (UK). I swapped the suspect power supply for a spare (both purchased at the same time). I’ve not had a random crash since then (at least 3 months ago).

I now use the ‘faulty’ USB-C power supply as a Chromebook charger, where it works fine (a momentary voltage glitch would not have any effect as it is just being used to charge a LiION battery).

Many RPi problems are caused by poor/faulty power supplies. Rule out the easy stuff first…

Ralph

random crashes were being caused by some fault on one of my ‘official’ USB-C RPi4 power supplies

They do seem to be prone to having a limited life.

The crashes on my Pi 4 are due to using a USB soft switch to change which machine the keyboard and mouse are attached to, occasionally switching will result in the Pi locking hard. It’s very annoying so most of the time I unplug the USB and use it via VNC. The other day I was doing quite a bit of work on it, so plugged in the USB and changed over the monitor input, and it was great, I’d forgotten how blindingly fast the full native experience is.

The crashes on my Pi 4 are due to using a USB soft switch to change which machine the keyboard and mouse are attached to

This sounds somewhat familiar. On my ARMX6, I have a 4-port kvm. Because I also have a couple of old computers connected to it, it’s a VGA type. Frequently when I switch to the ARMX6 I get no response from mouse or keyboard. Running applications are also stalled. In this state, if I connect over VNC, I see the same screen, I can move the VNC pointer, but get no response from it. (Note that the VNC connection does get accepted. Safestore and Hermes/Messenger however are stopped in their tracks.)

If I switch away and back, sometimes it will come back to life after one or two attampts, on other occasions I have to power it off – nothing else works.

It’s done this for the entire life of the ARMX6, so several major releases of RISC OS.

I had been thinking of connecting an rpi to one port of the kvm, and see whether it happens there too, but I think Dave has now done this test for me.

I can make this problem repeatable, to a high degree, by moving the mouse while the switchover is taking place.

Any thoughts on fixing this? Is there anything diagnostic I can use to feed more information to developers?

I run a Windows laptop, Linux laptop, ARMX6 & Pi4 running Kodi through an HDMI/USB/Audio KVM and switch many times a day without issue. I do remember having an issue with the ARMX6 not seeing the mouse after switching on a previous KVM though.

Frequently when I switch to the ARMX6 I get no response from mouse or keyboard.

It also happens on my ARMx6 mini.m but less frequently than the Pi4.

Ironically the mini.m just a test machine now, so I don’t mind that falling over, but having the Pi 4 lock up and lose the development environment, is yet another nail in the coffin of me doing any RISC OS stuff.

I had a new instance of this today. I was working on the ARMX6, opened a menu, moved down to select a submenu, and the machine locked up. As far as I know this is the first time I have had this happen while the KVM was switched to the ARMX6 and working.

I’m starting to get an impression that the “normal” problem might relate to activity on the ARMX6 while the KVM is looking elsewhere, i.e. it would not occur on a completely dormant computer. This might be a wrong guess though. The reason I think this is that often the “frozen” screen shows Hermes doing a fetch, or Safestore backing up files.

What I do see is when switching to the ARMX6:

Sometimes immediately after pressing the button to switch, the Num Lock on the keyboard briefly flashes on and off. If this happens, the ARMX6 will be working when the screen eventually syncs and the num lock comes back on to stay.

On the occasions when the ARMX6 is locked, there is no num lock activity after pressing the button to switch to it.

I used to see a similar problem where Netfetch/Hermes was stuck in a transfer or 7backup was stuck in progress during a backup, which seemingly points to a network issue. I no longer have this happening, and it was a few years ago now, so I can’t remember how I fixed or worked round it either now.

Hi Andy S,

Yes, I have run some tests on the hardware. I have two Raspberry Pi’s, one is a Pi4B with RISC-OS v5.28 and the other is a Raspberry Pi 400 running RISC-OS v5.29.
Both of them are doing the exact same thing, I have tried other power supplies but they do the same lockups.

Daniel.

Afternoon all,

I have done some testing and found a way to get the details of the freezing up i.e where the error comes from when the Pi4 freezes. Below is the list of error details.

15.02.2023 – Ran for 22Hrs
Internal error: abort on data transfer at &FC188308
*where FC188308
Address &FC188308 is at offset &00013548 in module `SharedCLibrary`

16.02.2023 – Restarted then ran for 19Hrs
Internal error: abort on data transfer at &FC18836C
*where FC18836C
Address &FC18836C is at offset &000135AC in module `SharedCLibrary`

Hope someone can help further…

Kind regards,
Daniel.

That narrows it down to a C based Module. If you can grab a full stack dump at the point it crashes, that should tell us which Module.

Not limited to just C based modules though. There could be a C based application that’s provoking the abort.

When you say ‘lockup’ do you mean there is no remote response as there’s a Wimp error box on screen?

Morning all,

Stuart: When I say lockup, I mean everything has frozen up, i.e. mouse & keyboard with no error box… The only way is to switch off and reboot.

Jon: How can I grab a full stack dump at the point it crashes?

Kind regards,
Daniel.

I mean everything has frozen up, i.e. mouse & keyboard with no error box… The only way is to switch off and reboot.

Long shot, as I’ve been having a similar problem. In my case I discovered that sometimes using VNCserver on the machine would allow it to be operated remotely.

In my case, the cause turned out to be a KVM that drew too much power from the USB1 ports on the ARMX6, causing USB reconnection to fail.

@ Daniel Garrod

I have done some testing and found a way to get the details of the freezing up i.e where the error comes from when the Pi4 freezes. Below is the list of error details.

Can you test without any 3rd party Modules and Applications software running? (aka no BBS software, no VNC if you have one etc.) – In other words can you isolate the problem by not running other software? Just RISC OS and using a standard boot process.

I guess you have already tried multiple power suppliers and, if you’re using a KVM, you surelly are using one of those “always on” and self powered units, otherwise you may have problems with switching back and forth to your Raspberry Pi.

So, excluding all power related issues, then it’s most likely some of the software you are running on it that is causing the problem. It could be a Module or even an Application.

Good luck,

I’ve had several lock ups with a completely clean boot and nothing running. The problem is almost certainly within the USB stack, rather than 3rd party software.

Like David I use a usb switch (to switch keyboard/mouse between computers) and the pi4 for me has always been a problem (random crashes etc), with a pi2 i get no problem.
The only way i can get the pi4 to work is not to use the Type A usb ports on the pi, for keyboard/mouse, but use the keyboard through the type C connector (ie the power port).
For this I use a laptop usb C hub (a ugreen thingy) so I can power the pi at the same time. Doing this I’ve not had a problem over the last few years.
This problem seems to of been around since day 1 for the pi4, and i’m pretty sure that what i’m doing was someones suggestion on this forum (?)

@ Druck and Jeff

Guys which KVM are you using with your Pis? I am using a TESmart 16 × 1, link below, and I never ever had an issue with any of my Raspberry Pis 4,3,2,1, PCs, RISC-V boards, FPGA boards etc. (that includes Pis 4 running RISC OS, of which one is on 24/7 by years now).

https://www.tesmart.com/products/tesmart-hdmi-kvm-switch-4k-uhd-3840×2160-60hz-16×1-16-in-1-out-kvm-hdmi-switcher-box-with-rs232-lan-port-support-hdcp2-2-16-port-hdmi-kvm-switch

The KVM is not cheap, but I use it to work as well and I have tons of SBCs and regular PCs connected to it as well as other KVMs that control racks of machines (one of which is full of old Acorn’s era RISC OS machines and also those are connected to the KVM above via a secondary and rack-local KVM). Never a single problem on any RISC OS system.

Hope this helps

Hi Paolo,
I don’t use a KVM, I use a usb switch, 1 input to 4 selectable output (logitech unifying receiver on the input for keyboard/mouse), for the video side I use a separate HDMI switcher.
As I said with the pi4 the way I set it up in 2019 got around the various pi4 issues with riscos (networking etc), and as it worked I’ve not bothered to change it since (actually I assumed the issue has been sorted out, evidently not).
In my testing (back in 2019/2020) I concluded it was a usb stack problem with the pi4 (as I said it works ok on the pi2), but also to bear in mind is that the 4 computers on the usb switch may all have a different idea of what earth is :-) so it could be a combination of software & usb switch hardware problems (and also the usb chipset in the pi that deals with stuff being connected/disconected).

As an aside I’ve recently got myself a rock5b, and it hates my HDMI switcher :-(

I’m also using an electric (soft) USB switchhttps://www.amazon.co.uk/gp/product/B01CU4QD1I/ to switch between two Raspberry Pi 4Bs, one Linux, one RISC OS, a Mini.M and a DisplayLink laptop dock. The Linux laptop and Linux Pi have never had any issue with switching, where as the Risc OS Pi and Mini.m do, which really points the finger at the RISC OS USB stack rather than any electrical issues.

This sounds like a problem I’ve been having on my ARMX6 for several years, solved last week.

I use a 4-port USB/VGA KVM. Two of the ports are for Windows 10 laptop and ARMX6, using HDMI-VGA adapters. The other two are for a RISC PC and an old desktop PC running Windows server2003. The KVM supports a wired keyboard and wireless mouse. The rpi and ARMX6 are running RO5.29, though the problem had been there since RO5.24. The RISC PC runs RO4.02, and doesn’t have the problem. Nor does Windows.

The problem is only seen when switching to the ARMX6. Occasionally, and more frequently if I move the mouse while it’s switching, the ARMX6 locks up.
There are several variations of lockup, of varying probability:

95% The ARMX6 is completely unresponsive. No pointer on screen. Anything running stops (no screen updates for instance). Sometimes switching away and back restores operation, most times I have to power off.

3% As above, but after 34 seconds it recovers. (The ones above that recover might be this version – I’ve only discovered the recovery time recently, and I might be too impatient.)

1% As first, but the machine can be accessed over VNC. The virtual pointer moves, but no button or keyboard response.

1% As third, but as soon as VNC connects, the machine recovers and the normal mouse and keyboard, and the virtual ones, all work.

I tried the setup with an rpi connected to the KVM. I did once manage to get a lockup there, in around 30 tests, and once got an error window saying “application error”, without identifying the application.

I thought the problem might be related to the power available to power the KVM from the USB port on the ARMX6, so I put a powered USB3 hub in between. The problem immediately went away.

However measurements show that the maximum current drawn to run the KVM is 50mA, i.e. much less than even a USB1 port can supply. An oscilloscope confirmed that there are no current spikes or voltage dips during switchover. The only fluctuation in current is when the keyboard Nums-lock light comes on, drawing an extra 10mA.

I then suspected the voltage, as the ARMX6 provides 5.03 volts, while the other machines are around 5.10 volts. However using a bench power supply to run the KVM, it worked normally down to 4.60 volts, and I didn’t try lower.

So I don’t think the reason the powered hub fixed the problem can be due to it’s power. However I suspect it’s changed the way the negotiation works.

It seems to me that the USB stack is insufficiently tolerant of failed negotiation. It does seem to have a timeout, but that doesn’t always take effect. Locking up isn’t an acceptable result.

I have also seen a lockup when using a RISC OS formatted SSD in a SATA-USB adapter. I can’t tell whether that was the USB part or the SCSIFS part looping though. Using a FAT32 format disc in the same adapter seems more stable.

Thanks for the details Jeff/Druck :)

So, without looking at what’s happening on your Pi (and the Rock 5B), so take my words with a grain of salt, it seems that your USB switch is not doing what (marketing) has called pass-thought. If you have an SD with a Linux distro for your Pi4 and for your Rock 5B, boot it up (even if they do not like the USB switch), connect to them from a laptop or something via SSH and runs some diag and tool like lsusb and check if they both identify the keyboard and mouse as the same hardware.

Other problems can come from a combination of keyboard/mouse and KVM/USB switch (some modern keyboard for example may require more juice than the KVM/USB switch can produce on the USB port and that will cause problems when switching, also with Linux running on your Pi4), others can have issues with their own power supply (if they are powered, so that can also cause this type of issue).

Other issues can come from the chips used on a USB switch (and on certain KVMs). At the latest SouthWest show I used a non self powered KVM for my RISC OS Cluster (4 Raspberry Pi cluster connected to a KVM and the KVM was powered via a modified laptop Screen which was powered via USB hub), surprisingly it all worked really well (but it was turned on just for a day, so I wouldn’t bet my money it could run stable for years).

One thing I have noticed is that some KVM is a bit slow at resetting itself, that is fine when powering it up while the Pis are powering on as well (Pis are usually are quite slow at getting to the init stage where they initialise keys and mouse), but causes troubles when the KVM runs out of juice or resets (for whatever reason) while a PI is already started. This is particoularly problematic when the USB switch or the KVM do NOT do the passthrough of both keyboard and mouse.

I would not bet my money on anything on RISC OS either lol (especially 5 seems to be tested in a very minimalistic way, so there are always chances to get issues here and there), however the above problems seems to be quite common with cheap USB switches/KVM, so I have observed them more often. Also, SBCs are, well cheap boards themselves, so I would never consider them having the same design and manufacturing quality of a more expensive PC, hence I treat them as “not reliable hardware”, just my personal approach.

Hope this helps,