Orange Pi 5+ should we have switched kernel?

Not that I’ve noticed, but I only tested the WiFi as far as checking that I could connect to my own ESSIDs and reach the Internet.
I prefer wired networking, even with the annoying ports-switching.
Hey, only two issues (the ports switching and very rare hang on reboot) for an entire device… is fine by me, others have it much worse, like only having a measly 8GB RAM, forever. ;-D

I’m tracking the interface swap here: Orange Pi 5 Plus | Network interface names can swap on reboot · Issue #6592 · MichaIng/DietPi · GitHub

Thanks for the link, @MichaIng! Following that one too now.
It is so very unfortunate, because apart from that network ports-switching and the very rare hang on reboot, this is just about the perfect at-home and probably also small-business server for running many services on the same device (and probably other tasks too, but that is the one I got it for and use it for), but then it is plagued by this.

Once the ports-switching issue has been fixed somehow, it would be nice to be able to configure both of the physical ports in dietpi-config alongside the wifi, instead of as now just one physical port, but until the ports-switching is fixed I guess most people do (or should) use both ports as if they are the same in different ways (as seen also in that GitHub-issue) so configuring a second physical network port would probably have little real benefit as long as the issue persists.

Hi, I’m trying to get bluetooth working on my orange pi 5+. I’m not sure if this is the right place or if I should start a new thread but this is the only thread I’ve found so far that references the same wifi module that I installed (RTL8852BE). I’m happy to open a new thread though if this discussion should go elsewhere.

I installed the kernel so the result of uname -a now reads

Linux dietpi 6.1.43-vendor-rk35xx #1 SMP Sat Apr 27 18:12:21 UTC 2024 aarch64 GNU/Linux

I have bluetooth enabled in dietpi-config but when I run hcitool dev it doesn’t show any devices. Should the kernel update have fixed anything related to bluetooth?

Huh. When I enable Bluetooth in dietpi-config the resulting process ends with

Setting up bluez (5.66-1+deb12u1) ...
Created symlink /etc/systemd/system/dbus-org.bluez.service → /lib/systemd/system/bluetooth.service.
Created symlink /etc/systemd/system/bluetooth.target.wants/bluetooth.service → /lib/systemd/system/bluetooth.service.
Processing triggers for libc-bin (2.36-9+deb12u7) ...
Processing triggers for man-db (2.11.2-2) ...
Processing triggers for dbus (1.14.10-1~deb12u1) ...
[  OK  ] DietPi-Set_hardware | APT install bluez
[  OK  ] DietPi-Set_hardware | systemctl enable --now bluetooth
[FAILED] bluetooth enable | Exited with error

So I looked in dmesg and the related output there seems to be this:

[10716.405025] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[10716.405059] Bluetooth: BNEP filters: protocol multicast
[10716.405084] Bluetooth: BNEP socket layer initialized
[10717.258663] Bluetooth: RFCOMM TTY layer initialized
[10717.258684] Bluetooth: RFCOMM socket layer initialized
[10717.258704] Bluetooth: RFCOMM ver 1.11
[10717.272741] Bluetooth: HIDP (Human Interface Emulation) ver 1.2
[10717.272768] Bluetooth: HIDP socket layer initialized
[10717.289407] Bluetooth: HCI UART driver ver 2.3
[10717.289426] Bluetooth: HCI UART protocol H4 registered
[10717.289432] Bluetooth: HCI UART protocol BCSP registered
[10717.289438] Bluetooth: HCI UART protocol ATH3K registered
[10717.289520] Bluetooth: HCI UART protocol Three-wire (H5) registered
[10717.289879] Bluetooth: HCI UART protocol Intel registered
[10717.290117] Bluetooth: HCI UART protocol Broadcom registered
[10717.290160] Bluetooth: HCI UART protocol QCA registered
[10717.290166] Bluetooth: HCI UART protocol AG6XX registered

…but those are not errors, so I guess the error-message must have been sent elsewhere.

I hadn’t even tried using the Bluetooth until now, because I didn’t need to, so that was the behavior on a fresh first attempt.

You know what - I just disabled & re-enabled bluetooth and I’m seeing the same Exited with error but dietpi-config reports that bluetooth is “On” (though I guess this is just what it stored regardless of whether it was successfully enabled).

Yep, same here. Even after the “Exited with error”, dietpi-config claims that Bluetooth is “On”.
It should probably not do that in any cases of any non-success exit-codes.

Found and fixed the reason: v9.4 · MichaIng/DietPi@03b8282 · GitHub
However, it is visual only. The last successful command was the last to be applied. After that, a conditional was wrong, leading to a non-zero return code of the function. So [On] is correct as well.

@cchaz003 did Bluetooth work for you with the legacy 5.10.160 kernel? Else I suggest to open a new issue/topic.

Yes, this did happen on the previous kernel as well. I’ll open a new issue then.

Is there a good reason to revert the kernel back to 5.10.160? And where would I download that kernel package if I did? Thanks!

Not, unless the upgrade broke something for you. I aim to move all RK3588 boards to this kernel anyway, just waiting for one test on NanoPC T6.

Hmm, I tested the vendor kernel on my Orange Pi 5 Plus, and it causes in infinite udev reload loop with persistent 5% CPU usage, due to one HDMI related device: Orange Pi 5 Plus | Network interface names can swap on reboot · Issue #6592 · MichaIng/DietPi · GitHub

While debugging our udev rule which assures fixed Ethernet interface names, the systemd journal was regularly written full and rotated due to the udev log spam.

Do you (anyone) as well see a udev worker process in your htop which never settles?

Hmm, yes, after I tested to see that the new rules with reliable workaround for the wired ethernet ports switching was working fine through 25 reboots, with only 2 of the seemingly unrelated hang-on-reboot-exit thingies, I went to look at this too and in in htop I see one (udev-worker) and one /lib/systemd/systemd-udevd seemingly constantly chilling at 2-5% CPU. The (udev-worker) process ID in ps says it is [kworker/5:0+events].
This was while the machine had no other interactive use than htop/btop/ps.

Okay that one will be it. I’ll do some testing when I find time, e.g. whether having an HDMI screen attached to the related port helps, and which port it is. Maybe we can find some responsible node in the decice tree which causes it and at best some fix.

Comparing with Xunlong’s 6.1 sources and at best testing with a build of their unmodified sources makes sense. So in case we can report it at the Xunlong repo.

Hey, @MichaIng, now my Orange Pi 5+ got an update through APT making the kernel Linux [REDACTED] 5.10.160-legacy-rk35xx #1 SMP Wed May 15 03:04:45 UTC 2024 aarch64 GNU/Linux instead of this Linux [REDACTED] 6.1.43-vendor-rk35xx #1 SMP Sat Apr 27 18:12:21 UTC 2024 aarch64 GNU/Linux which we previously got working.