root@DietPi:~# ip l
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
link/ether e2:57:59:18:e4:4a brd ff:ff:ff:ff:ff:ff
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DORMANT group default qlen 1000
link/ether f4:e4:dc:4d:b4:4b brd ff:ff:ff:ff:ff:ff
root@DietPi:~# dmesg -l 0,1,2,3
[ 0.351932] dw-apb-uart 5000000.serial: Error applying setting, reverse things back
[ 0.352480] sun6i-spi 5010000.spi: Error applying setting, reverse things back
[ 0.359437] sunxi-mmc 4021000.mmc: Error applying setting, reverse things back
[ 0.360410] sunxi-mmc 4020000.mmc: Error applying setting, reverse things back
[ 0.360531] dw-apb-uart 5000000.serial: Error applying setting, reverse things back
[ 0.707554] WCN_ERR: dts node for bt_wake not found
[ 3.040951] ac200-sunxi 1-0010: probe with driver ac200-sunxi failed with error -22
[ 9.254132] wifi ini path = /lib/firmware/wifi_2355b001_1ant.ini
[ 9.289890] sprdwl:sprdwl_get_fw_info length mismatch: len_count=83, r_len=89
[ 9.296694] sprdwl:sprdwl_get_fw_info, drv_version=1, fw_version=2, compat_ver=0
[ 9.303757] sprdwl:chip_model:0x2355, chip_ver:0x0
[ 9.303775] sprdwl:fw_ver:0, fw_std:0x7f, fw_capa:0x120f7f
[ 9.303779] sprdwl:mac_addr:5c:8a:ae:32:dc:77
[ 9.303785] sprdwl:credit_capa:TX_WITH_CREDIT
[ 9.303789] sprdwl:ott support:0
[ 12.092783] sunxi-gmac 5030000.ethernet eth0: No PHY found!
[ 12.106978] sunxi-gmac 5030000.ethernet eth0: phy init again...
root@DietPi:~#
there is no information within the system log about a reason for the crash.
Yes Joulinar
After some search, it 's the Ethernet socket who is in power default when the system crashed down
Can you explain a bit more?
Btw, is WiFi enabled intentionally? As I always suspect that driver to cause issues, might be worth testing to disable it, and see whether the system runs stable then.
Hello @MichaIng
Yes, indeed, Wi-Fi works simultaneously with Ethernet. I can connect via Wi-Fi using SSH while the OPI Zero 2w is connected via eth0 and playing music (LMS) or video (Kodi).
Note that I tested with the older kernel 6.12.76 and it works the same way without any bugs, I downgraded the kernel and everything works perfectly with version 6.12.76 to verify that the bug was indeed caused by kernel 6.18.
Have a good day
Thank you. I have just found some time to try this out.
Yes I am using the official expansion board.
I am using the official expansion board. I actually realized that I didnt reboot properly after the update. Sorry for the late reply. I tried rebooting again and it worked fine for a few days, but suddenly it lost the ethernet connection, so I am trying the kernel downgrade for now. Yes the WiFi does work.
My dmesg looks the same as @Totof
To find out whether the WiFi driver is the culprit (in combination with the new kernel), it would be interesting to see whether the system runs stable if WiFi is disabled.
The system logs indeed do not give a hint, also the timestamps after network time sync show that the last log entry was several minutes before the crash. Looks like it was abrupt enough to prevent the system from processing any further log.
I’m going to update to kernel 6.18 and disable Wi-Fi.
I’ll back up my system first for safety.
Then I’ll test your suggestion and let you know.
Quick evening test
It’s worse when disabling Wi-Fi via dietpi-config.
LMS works.
But Kodi crashes when starting DVDs.
It can play MP4 videos, but as soon as I try to access the settings to test it, it freezes and the Ethernet port indicator lights stay fixed on.
Wasn’t Kodi using the Ethernet before as well? I.e. Internet access/default gateway was via Ethernet, and WiFi did only have a static local address for SSH, isn’t it?
Anyway, whether it may be difficult to derive whether disabling WiFi makes anything worse or not, at least we know now that it is not the culprit.
So it seems the sunxi-gmac driver, while it compiles with Linux 6.18, seems to have some issues with that version. Without any kernel error, we have no clue, and I do not see any sources of the driver ported to mainline besides this Armbian patch. Since it is “only” about the expansion board, and the SBC itself was and is already a way above average source of trouble and time sink, I’m not going to grop around in the dark for this. When using the expansion board for Ethernet, downgrading the kernel is a workaround. If anyone is able to catch a kernel/system error about the issue, please post it here. And above one can find all links to the patches which add/enable this driver. Maybe someone with more experience or the help of AI can find something causing such issues with Linux 6.18.
Hi @MichaIng
You’re absolutely right, it worked perfectly with Kernel 6.12.
I’ll leave it as is. If I find anything else, I’ll post an update.
I’ll continue testing next week because I have a big sports weekend.
Thank you so much for all your time.
I give up. Reverting made it worse. Its too broken and unstable. Ill go dig out my previous dietpi img from last month and start from scratch again.
How confident is everyone that this was resolved?
I have a Opi Zero2W and it was running fine for months, then on the latest update to 10.3.3, it now just segfaults constantly.
I grabbed a fresh image on a fresh SD card but as soon as the wireless kernel module is loaded (enabling wifi through dietpi-config), it just locks up, sometimes I get a segfault, other times it just freezes. I think there are still issues with the network stack for OPI.
Hello
For this moment i downgrade the kennel like mentionned upside
My two boards work like a charm with the kennel 6.12.76
One is under bookworm, the other under trixie
Not shure to go forward with this board, i have a look to the radxa zero 3w with rk3566
Hi all
Hi @MichaIng
After the upgrde to the V10.4.2 version and a few days of test on my two OPI zero 2w board, here is some tips
The two boards are with the official expension board and run my script for activate the i2s0 functionality
The first one connected via ethernet work well with the 6.12.76 kernel
with the 6.18.29 version it doesn’t work like before
the second one connected via wifi work with the kernel 6.18.29 and a minidsp
is attached to it via the usb port of the expension board
So i continue to listen my music with this two board as is 
Everyone who is using the old Linux v6.12 build, please apply Copy Fail and Dirty Frag mitigations, else every user with console access can obtain root privileges without any authentication:
printf 'install algif_aead /bin/false\nblacklist algif_aead\n' | sudo tee /etc/modprobe.d/copyfail.conf
printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' | sudo tee /etc/modprobe.d/dirtyfrag.conf
printf 'blacklist esp4\nblacklist esp6\nblacklist rxrpc\n' | sudo tee -a /etc/modprobe.d/dirtyfrag.conf
sudo modprobe -r algif_aead esp4 esp6 rxrpc
echo 3 | sudo tee /proc/sys/vm/drop_caches
Thanks @MichaIng , it’s done for me
Armbian replaced the vendor sunxi-gmac driver with bindings for the mainline dwmac-sun8i driver for a new “mainline-quality” AC300 PHY driver: Feature/sunxi mainline stmmac ac300 by deece · Pull Request #9952 · armbian/build · GitHub
I’ll revert our patches and generate a test build. This looks promising.
EDIT: Ready for testing:
G_DEV_TEST_FIRMWARE
Good evening @MichaIng
That’s great news! I’ll try it out as soon as possible and get back to you with the results.
Tomorrow and this weekend I’m in organizing a swimrun in the south of France (Hérault), so not at home. However, I think I’ll be able to test it next week.