Hi Pierre,
sorry for the delay to answer.
I got to boot it and have it stable by applying this patch, sent by a dev
offlist:
Index: sys/dev/ic/re.c
===================================================================
RCS file: /cvs/src/sys/dev/ic/re.c,v
diff -u -p -u -p -r1.218 re.c
--- sys/dev/ic/re.c 12 Aug 2024 06:47:11 -0000 1.218
+++ sys/dev/ic/re.c 30 Aug 2024 08:25:52 -0000
@@ -774,8 +774,8 @@ re_attach(struct rl_softc *sc, const cha
sc->rl_flags |= RL_FLAG_FASTETHER;
sc->rl_max_mtu = RL_MTU;
} else {
- sc->rl_flags |= RL_FLAG_JUMBOV2 | RL_FLAG_WOL_MANLINK;
- sc->rl_max_mtu = RL_JUMBO_MTU_9K;
+ sc->rl_flags |= RL_FLAG_WOL_MANLINK;
+ sc->rl_max_mtu = RL_MTU;
}
sc->rl_flags |= RL_FLAG_PHYWAKE | RL_FLAG_PAR |
I was told that this was a workaround. This was pre-7.6 time.
Not long since that test I had to use the R4SE on another place and didn't run
OpenBSD on it.
If there is work on this again, I can work here to test again :)
matheus
August 16, 2025 at 9:54 AM, "Pierre Louis Aublin" <[email protected]
mailto:[email protected]?to=%22Pierre%20Louis%20Aublin%22%20%3Cpl%40pakupaku.me%3E
> wrote:
>
> Hi
>
> Please forgive me to revive this old thread, but I faced the same issue on my
> newly acquired R4S and OpenBSD 7.7. This email is divided in 2 parts:
> 1. Solution to the boot problem
> 2. Kernel panic when using the LAN network interface
>
> 1. Solution to the boot problem
> -------------------------------
>
> I managed to boot the kernel after installing the system by copying
> `rk3399-rockpro64.dtb` instead of `rk3399-nanopi-r4s.dtb` to the `/rockchip`
> folder on the boot partition. The idea came from this post (in Chinese, but
> used Google Translate): https://blog.starry-s.moe/posts/2022/nanopi-r4s/ .
>
> Here are some relevant lines observed during the boot process:
> ```
>
> [...]
>
> dwmmc0 at mainbus0: 50 MHz base clock
> sdmmc0 at dwmmc0: 4-bit, sd high-speed, mmc high-speed, dma
>
> [...]
>
> scsibus0 at sdmmc0: 2 targets, initiator 0
> sd0 at scsibus0 targ 1 lun 0: <SD/MMC, 00000, 0000> removable
> sd0: 59640MB, 512 bytes/sector, 122142720 sectors
> vscsi0 at root
> scsibus1 at vscsi0: 256 targets
> softraid0 at root
> scsibus2 at softraid0: 256 targets
> root on sd0a (3ee1d4d5039301c4.a) swap on sd0b dump on sd0b
>
> [...]
>
> Automatic boot in progress: starting file system checks.
> pf enabled
> starting network
> reordering: ld.so libc libcrypto sshd sshd-session sshd-auth ssh-agent.
> starting early daemons: syslogd pflogd ntpd.
> starting RPC daemons:.
> savecore: no core dump
> checking quotas: done.
> clearing /tmp
> kern.securelevel: 0 -> 1
> creating runtime link editor directory cache.
> preserving editor files.
> starting network daemons: sshd smtpd sndiod.
> starting local daemons: cron.
> Sat Aug 16 20:37:38 JST 2025
>
> OpenBSD/arm64 (openr4s.my.domain) (console)
> ```
>
> It seems the following lines are missing from
> `https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/tree/src/arm64/rockchip/rk3399-nanopi-r4s.dtsi%60
> (used among others by `https://github.com/Tosainu/nanopi-r4s-u-boot%60 to
> create the dtb file):
> ```
> +&sdmmc {
> + status = "okay";
> +};
> ```
>
> Besides the problem detailed below, I have not encountered any other problem
> while using OpenBSD.
>
> 2. Kernel panic when using the LAN network interface
> ----------------------------------------------------
>
> The kernel panics when running iperf with another machine over the LAN
> network interface (re0). This does not happen with the WAN network interface
> (dwge0). While the MAC is set to 00:00:00:00:00:00 by default as the board
> doesn't have the chip to store it, I've set it to a valid, random value
> before the test.
>
> ```
> # panic: pool_cache_item_magic_check: mcl9k cpu free list modified: item addr
> 0xf
> fffff801ecbd500+16 0x400000c9000045!=0xc3b51ecae9362bf1
> Stopped at panic+0x140: cmp w21, #0x0
> TID PID UID PRFLAGS PFLAGS CPU COMMAND
> 438354 35240 0 0x3 0x4000000 4 iperf
> 202876 99382 0 0x14000 0x200 1 softnet0
> db_enter() at panic+0x13c
> panic() at pool_cache_get+0x264
> pool_cache_get() at pool_get+0x54
> pool_get() at m_clget+0x1c8
> m_clget() at re_newbuf+0x44
> re_newbuf() at re_rxeof+0x390
> re_rxeof() at re_intr+0xc0
>
> ddb{0}> trace
> db_enter() at panic+0x13c
> panic() at pool_cache_get+0x264
> pool_cache_get() at pool_get+0x54
> pool_get() at m_clget+0x1c8
> m_clget() at re_newbuf+0x44
> re_newbuf() at re_rxeof+0x390
> re_rxeof() at re_intr+0xc0
> re_intr() at agintc_irq_handler+0x104
> agintc_irq_handler() at arm_cpu_irq+0x44
> arm_cpu_irq() at handle_el1h_irq+0x68
> handle_el1h_irq() at cpu_idle_cycle+0x28
> cpu_idle_cycle() at sched_idle+0x218
> sched_idle() at proc_trampoline+0xc
> ```
>
> By any chance, would you have any idea to debug or solve this problem?
>
> Best regards
> Pierre Louis
>
------------
"We will call you Cygnus,
The God of balance you shall be."
