RPi 4B with RISC-OS 5.28 & 5.29 Lockups

@ Alan Adams

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.

Aren’t the USB ports of the ARMX6 already obtained by using a USB HUB internally? Sorry I do not remember, but on the back of my head I have this thought. If my rusty memory is correct, it may be worth checking if that internal hub is powered on not.

Hi David,
Like you I do usb switch a pi4 running linux (with keyboard on its main usb type a ports), and like you I don’t have any problems.
So I go along with you that there is a usb stack problem, but I wouldn’t be surprised to find if the software problem is caused by the usb receiving fun electrical activity during the switching period.
My guess is that Paolo expensive KVM is way better electrically than my £5 usb switch, and also there are a lot more linux guys & girls working the usb stack to sort out this sort of thing.
I still remember playing with electronics many many many decades ago and the damn problem of ‘key bounce’ had on my little projects……

Hi Paolo,
Thanks for showing some care about my Rock 5B :-)
Rock 5B is happy with its usb setup, I can ssh into it ok and it says the usb is fine and dandy, the HDMI problem with it is very probably a rock chip/bodged linux 5.10 problem, basically if rock wakes up from slumber and there’s no HDMI connection to it, it aint going to connect to the HDMI again…. trying to get the rock not to slumber did not work out. so it is now going to live else where in my office where it can live happily with its own monitor.
Back to topic… I agree with your grain of salt!!!

Hummm I wonder if it’s something happening in ehci_intr1…

Thanks for showing some care about my Rock 5B :-)

I have a Rock 5B too! It’s an awesome SBCs, I have got the 16GB RAM model, it’s totally awesome to run Linux, yes the Radxa kernel is a bit of a mess. What I meant with the “always on” mentioning in one of my earlier post is that my KVM leaves the HDMI port on and copies the EDID on it, so I handle that problem this way.

I started to have a look at that kernel to list all the fixes and eventually port them to 6.10, but had no time yet, plus given I solved the issue using my KVM, it’s now a lover priority for me.

The USB switching lock up isn’t an electrical issue. With two identical Raspberry Pi 4B’s ONLY the RISC OS one locks up, the Linux one doesn’t. With an ARMx6 mini.m ONLY when running RISC OS does it lock up, Linux doesn’t.

There’s only one place to look at for this fault, and that’s the software.

The USB switching lock up isn’t an electrical issue.

Druck, please, don’t take it like I am trying to prove you wrong jeez. I am trying to figure out what is happening with your USB Switch.

For your remark Linux is fine and RO is not, while I believe you, there is also a tons of folks that had similar issues with Linux on the Raspberry Pi 4:

https://forums.raspberrypi.com/viewtopic.php?t=275492

https://forums.raspberrypi.com/viewtopic.php?t=18195

In general it seems that the Pis B+ are more suitable for this type of things. I am not saying that there isn’t a problem on the RISC OS USB Stack, but it’s very much likely that the issue IS being triggered by an electrical or signal problem from which the RISC OS USB stack doesn’t recover well.

If it was just a bug in the RISC OS USB stack, then it should manifest with ALL switching, not just with specific devices, don’t you agree? Hence, I mentioned with my KVM I have never experienced this (not even once).

If it was just a bug in the RISC OS USB stack, then it should manifest with ALL switching, not just with specific devices, don’t you agree?

Speaking as a support person of a little number of years – no.

It very much depends on the mode you’re using the USB interface and the timings of switching edges vs. the timing loops/delays of the software.
A non-RO and non-ARM hardware I can quote involves a model of Apricot PC that worked fine with Win95, but locked the moment you touched a key or moved the mouse when running Win311. That involved a driver waiting a fixed period before looking for an i/o response and missing the response that had already come from the optimised hardware, having delivered it before the end of the aforesaid fixed period.

Equally, I wouldn’t agree with Druck in the assumption that it absolutely is not a power issue, if it is even remotely possible that the reduced power level rounds off/delays switching edges.

Change what can be changed easily and if that makes a difference then you have a contributory item to the perceived fault – which may not be the fault¹ but a factor that exacerbates an edge case into out of spec.

¹ Anyone who believes in singular faults in a system is living a life of self-delusion.

Here’s the USB events from kern.log, connecting:

Feb 28 19:54:34 RPi-S kernel: [2709018.025035] usb 1-1.4: new high-speed USB device number 94 using xhci_hcd
Feb 28 19:54:34 RPi-S kernel: [2709018.127754] usb 1-1.4: New USB device found, idVendor=2109, idProduct=2811, bcdDevice=91.00
Feb 28 19:54:34 RPi-S kernel: [2709018.127793] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Feb 28 19:54:34 RPi-S kernel: [2709018.127810] usb 1-1.4: Product: USB2.0 Hub
Feb 28 19:54:34 RPi-S kernel: [2709018.127822] usb 1-1.4: Manufacturer: VIA Labs, Inc.
Feb 28 19:54:34 RPi-S kernel: [2709018.130141] hub 1-1.4:1.0: USB hub found
Feb 28 19:54:34 RPi-S kernel: [2709018.131216] hub 1-1.4:1.0: 4 ports detected
Feb 28 19:54:34 RPi-S kernel: [2709018.444986] usb 1-1.4.1: new full-speed USB device number 95 using xhci_hcd
Feb 28 19:54:35 RPi-S kernel: [2709018.564458] usb 1-1.4.1: New USB device found, idVendor=046d, idProduct=c52b, bcdDevice=24.11
Feb 28 19:54:35 RPi-S kernel: [2709018.564479] usb 1-1.4.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Feb 28 19:54:35 RPi-S kernel: [2709018.564485] usb 1-1.4.1: Product: USB Receiver
Feb 28 19:54:35 RPi-S kernel: [2709018.564491] usb 1-1.4.1: Manufacturer: Logitech
Feb 28 19:54:35 RPi-S kernel: [2709018.585674] logitech-djreceiver 0003:046D:C52B.0080: hiddev96,hidraw0: USB HID v1.11 Device [Logitech USB Receiver] on usb-0000:01:00.0-1.4.1/input2
Feb 28 19:54:35 RPi-S kernel: [2709018.759687] logitech-hidpp-device 0003:046D:408A.0081: HID++ 4.5 device connected.
Feb 28 19:54:35 RPi-S kernel: [2709018.867616] logitech-djreceiver 0003:046D:C52B.0080: device of type eQUAD step 4 DJ (0x04) connected on slot 2
Feb 28 19:54:35 RPi-S kernel: [2709019.243706] logitech-hidpp-device 0003:046D:408A.0081: hidpp20_batterylevel_get_battery_info: received protocol error 0x06
Feb 28 19:54:35 RPi-S kernel: [2709019.406107] input: Logitech MX Keys as /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.4/1-1.4.1/1-1.4.1:1.2/0003:046D:C52B.0080/0003:046D:408A.0081/input/input72
Feb 28 19:54:35 RPi-S kernel: [2709019.406703] logitech-hidpp-device 0003:046D:408A.0081: input,hidraw1: USB HID v1.11 Keyboard [Logitech MX Keys] on usb-0000:01:00.0-1.4.1/input2:1
Feb 28 19:54:36 RPi-S kernel: [2709020.061917] logitech-hidpp-device 0003:046D:4082.0082: HID++ 4.5 device connected.
Feb 28 19:54:36 RPi-S kernel: [2709020.400402] input: Logitech MX Master 3 as /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.4/1-1.4.1/1-1.4.1:1.2/0003:046D:C52B.0080/0003:046D:4082.0082/input/input73
Feb 28 19:54:36 RPi-S kernel: [2709020.402523] logitech-hidpp-device 0003:046D:4082.0082: input,hidraw2: USB HID v1.11 Keyboard [Logitech MX Master 3] on usb-0000:01:00.0-1.4.1/input2:2

Disconnecting:

Feb 28 19:54:43 RPi-S kernel: [2709026.652344] usb 1-1.4: USB disconnect, device number 94
Feb 28 19:54:43 RPi-S kernel: [2709026.652366] usb 1-1.4.1: USB disconnect, device number 95

The mice and keyboard wireless from a Logitech dongle which is plugged in to the monitor’s USB 2 hub which is plugged in to the switch (legacy from when I needed wired keyboard and mouse both connected and the switch only switches one device).

If it was just a bug in the RISC OS USB stack, then it should manifest with ALL switching, not just with specific devices, don’t you agree?

No, that’s nonsense. There can be variations in the way that different hardware (such as KVMs) implement USB, which all fall within the standard but don’t all play well with the (some of) the USB implementation(s) used by RISC OS. I know that firmware and software engineers like to blame the hardware engineers, but over the years that I’ve been (primarily) a hardware engineer, I reckon the score has probably been about even. :-)

FWIW, I thought at least one common factor was the XHCI module on the Pi 4 and Titanium? I can certainly get neither machine to switch with my KVM (the system freezes on the first return of the keyboard and mouse to the RISC OS box, requiring an Alt-Break to clear it and naming the aforementioned module in the process). The same KVM is happy with the non-XHCI USB on a couple of Beagleboards, however.

XHCI module on the Pi 4 and Titanium

Interesting, as my FOURtress (a Pi 4 based system) has been the most reliable switching of the set of Pi 1, Pi 3B, ARMX6 with my KVM. I do have a powered hub between the keyboard/mouse and the RISC OS systems though.

@ Steve

No, that’s nonsense. There can be variations in the way that different hardware (such as KVMs) implement USB, which all fall within the standard but don’t all play well with the (some of) the USB implementation(s) used by RISC OS.

What is nonsense, sorry? You do realise we are saying the same thing right?

My point was, there can be a number of things on the device (either firmware or hardware) that can be causing a behaviour that is not fully expected by the USB stack (or even causing side effects in the USB stack code). Certainly is not a behaviour triggered by every device and so it’s something on the device that is triggering the problem.

Now, if we need to insist of “commas”, “dots”, “semantics”, sure let’s have fun talking about nothing useful, I am sure this type of activity is going to be very valuable also for who may have similar issues in the future. XD

You do realise we are saying the same thing right?

As far as I can see, I’m saying the same thing as Steve P and Druck – and they appear to be disagreeing with you, too… :-)

As far as I can see, I’m saying the same thing as Steve P and Druck

That is surelly an interesting statement Steve, given Steve P doesn’t seems to agree with Druck as per his words:

Equally, I wouldn’t agree with Druck in the assumption that it absolutely is not a power issue

In any case, I am not 100% sure they have read my comments through, in the end this forum is quite famous for that, so I give up, clearly you’re interested in something else but finding the problem someone is having.

As a technical info: my 2 RPi4 are working fine also with a USB Switch (just finished testing), so probably it’s the case that someone with desire to help the two users looks at a bit more details on the USB Switch being used by them.

Hope this post have enough commas, dots and sematics for Steve Fryatt to actually understand what I meant :)

As far as I can see, I’m saying the same thing as Steve P and Druck – and they appear to be disagreeing with you, too… :-)

Disagreeing with Druck too, in that absolutely ruling something out on slim or no evidence is always a bad idea. Too many non-binary items around.
I want to see more info.

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.

While I would agree that the little boards are made to a budget, these days I’m not sure I’d agree that the big boards are necessarily any better. They’re just in a nicer looking box…

On the subject of software USB lockups, since KinoAmp can read DVDs just fine, I have experimented at home with a little program to backup my DVDs. Since it doesn’t cope well with DVDs were the copy protection consists of bad sectors (the time spend on trying to read each of these bad sectors is far too long), I tried to interrupt the program but the machine freezes, sometime instantly, sometimes after a delay that never exceeds 30 seconds. This suggest to me that something in the CD driver → SCSI → USB chain leave some background routines in a bad state.

Disagreeing with Druck too, in that absolutely ruling something out on slim or no evidence is always a bad idea.

On the contrary, I can provide plenty of evidence that on two entire different machines (Raspberry Pi 4B and ARMx6 Mini.m) which can run both RISC OS and Linux, it is only under RISC OS that crashes when the USB is switched.

What more do you need? A clap of thunder and a big booming voice from the sky?

Just for some balance. I have an ATEN VGA/USB switch which has a wired Keyboard and a wireless mouse connected (no VGA connection in use nowadays) and this works without fail between a Windows 10 PC, a Windows 10 Laptop, an ARMX6 and a 4te2 now (was a Raspbeery Pi 1B).

I am also using a UGREEN 3 way HDMI switch and this also switches fine been the laptop/ARMX6/4te2

But I had one switch previously for the USB they simply would not pickup the connection on switching between computers.

Had a couple of errors when switching USB input devices on a Mini.m which may be related to hang on the Pi 4B.

*where
Address &FC21C234 is at offset &000067E8 in module 'USBDriver'
*where &fc21c22c
Address &FC21C22C is at offset &000067E0 in module 'USBDriver'
*h. usbdriver
==> Help on keyword USBDriver
Module is: USBDriver       1.31 (04 Jul 2020)

I just discovered this thread but having spent 10 days throwing everything at a serialusb bug that freezes the machine when it is receiving data and you close the usb endpoints only for the problem to disappear when plugged into the dwcdriver my money is on the xhcidriver – the usbdriver module is the same for both backends. As druck says linux has no problems so it’s not the devices that are attached. A freeze while switching a keyboard/mouse may be due to the device bouncing when connecting and the xhci driver having problems with disconnecting in certain situations.

I run my pi4 from the charger connection of a powered hub. Since picking up riscos again, and updating roms, the pi4 won’t start with the data connector of the powered hub connected via xhci but it does if connected via the dwcdriver. And linux has no problems either way. When starting connected to xhci it stops where usb is enumerating devices the screen is blank after the bootloader flash screen disappears and no usb device is enumerated.