I’m seeing the following updates available on both of my RockPi4 devices (one is on the 6.1.63 kernel I manually updated to for testing), and the other device’s kernel was not manually upgraded.
On my non-upgraded device, I saw that a reboot was required in order to complete the kernel upgrade. Will this downgrade my manually upgraded kernel, and since the manually upgraded kernel is still failing to get USB3 working, is this fine to do?
Edit: I ran these updates on my 2nd RockPi which was on kernel 6.1.50. This device is at my office and I accessed it remotely today to trigger the post-upgrade reboot. I was unable to SSH into it afterward. I had a coworker unplug/replug power and I’m still unable to SSH into it. I’ll try myself on Monday (with and without disconnecting the attached USB hard drives) and see if I can get it to boot again.
So Armbian has pushed v23.11.1 with Linux 6.1.63 to their APT servers quickly, which is great.
This is not a downgrade, but an upgrade, at least of the build system’s version, while the kernel version is exactly the same of the packages I provided above: 6.1.63
Hence I am quite surprised that this upgrade (if I understood correctly) broke booting (or network) of one of your systems, while our packages (based on Armbian 23.11.0) worked well? Would be horrible if a point release of Armbian’s build system broke something so critically.
Btw, to get USB 3.0 back to work, currently one must downgrade to Linux 5.15 (Armbian 23.02.2):
apt install linux-{image,dtb}-current-rockchip64=23.02.2
apt-mark hold linux-{image,dtb}-current-rockchip64
Just from security perspective it is not great, since this is a kernel dot version from soon a year ago, including all vulnerabilities which might have been found in the meantime.
Thank you @MichaIng for clarifying the related kernel versions involved with these upgrades.
Losing the ability to SSH into my devices following a reboot feels like a 50/50 thing honestly. I don’t have data to support that, but I’m very used to having to unplug and replug multiple times following a systemctl reboot and I expect that could be the case there. I almost always have some external USB drive hooked up in these systems, and occasionally I have to physically unplug those in order to boot the Pi (Rock, Raspberry, etc) successfully. Maybe this is just me.
Thank you as well for the instructions on getting back to Linux 5.15 (Armbian 23.0.2). Now that I’ve completed my large rsync tasks over USB 2.0, there’s not as big of a need for 3.0 speeds for me, so I’ll probably wait for an upstream fix (hopefully).
Edit/Update: My RockPi that was failing to boot was resolved by powering off my external USB drives. Once I shut the drives down, the blue activity light started blinking and it completed the boot process. No idea why this would hang.
Hmm, probably the bootloader somehow tries to and fails to boot from the attached USB drives? A USB-UART adapter (serial console) could reveal this. If the LEDs change now and did not do this before, this usually indicates the kernel was previously not loaded yet, hence it was still in bootloader stage.
Some new updates are available today. I haven’t had a chance to look into what they include/fix etc.
4 packages can be upgraded. Run 'apt list --upgradable' to see them.
Listing... Done
armbian-firmware/bookworm,bookworm 24.2.1 all [upgradable from: 23.11.1]
linux-dtb-current-rockchip64/bookworm 24.2.1 arm64 [upgradable from: 23.11.1]
linux-image-current-rockchip64/bookworm 24.2.1 arm64 [upgradable from: 23.11.1]
linux-u-boot-rockpi-4b-current/bookworm 24.2.1 arm64 [upgradable from: 23.11.1]
Looks like they may have moved the kernel to 6.6 (getting closer to the 6.7 that’s claimed to fix the USB 3.0 bug) although there are also references to 6.7 in the changelog. Not sure how to read this: https://docs.armbian.com/Release_Changelog/
“current” is now Linux 6.6 and “edge” is Linux 6.7. Where do you see that USB 3.0 is fixed? That would be great, of course.
EDIT: Or you mean upstream Linux 6.7 solved the USB 3.0 bug? Would be basically assured that it has been fixed for Linux 6.6 then as well: Linux backports bug fixes to supported LTS versions.
Ah right. Would be great if someone could test it, and HDMI as well on the boards where it did not work. I have only a NanoPi R4S with this SoC, which has not HDMI and functional USB 3.0.
I did some initial test writes of 5+GB of data to a USB 3.0 flash drive plugged into the 3.0 ports on my ROCK 4 and didn’t encounter any issues. I’ll do more testing with larger and longer running rsync processes on my home server to see if it also holds up. Looking good so far.
If I understood and as far as I re-read the topic, devices plugged into the USB 3.0 port, were not detected at all. So if you can mount them, the issue has been fixed, hence no need to run further tests.
That might be true for the top-most USB 3 port. My drives were mountable on the lower USB 3 port but I was seeing failures doing large rsync transfers. I mention it in this post, and the post that I link to directly under it also notes the same failures:
The test I did with the flash drive today was on the top port. I also did a large file transfer from a drive hooked up to the bottom 3.0 port, but I believe the drive adapter on that device is only 2.0 capable. The transfer also succeeded (~40GB of data), but I’d like to still test larger rsyncs on the bottom 3.0 port with a 3.0 capable conventional hard drive.
Okay, but that would be then an entirely different issue. I/O errors can have a lot of different reasons, which may or may not at all be related to the kernel, but PSU, USB voltage and other things down to physical reasons, or which drive/adapter you use. The original issue, that the driver fails to load entirely, respectively fails to load the particular USB host, at least has been solved.