On Sat, Apr 04, 2026 at 11:16:35AM +0200, Kirill A. Korinsky wrote: > On Fri, 16 Jan 2026 18:01:52 +0100, > Klemens Nanni <[email protected]> wrote: > > > > ddb{0}> bt > > cnmac_recv_mbuf+0x134 (77e060040f88a,1,980000000fd97a00,980000000fd979fc) > > ra 0xffffffff8132c9fc sp 0x980000000fd979d0, sz 32 > > cnmac_recv+0x7c (77e060040f88a,1,980000000fd97a00,7ac0a7ce8aab3e1f) ra > > 0xffffffff8132aa2c sp 0x980000000fd979f0, sz 80 > > cnmac_intr+0xfc > > (77e060040f88a,247c372c96c2746a,980000000fd97a00,7ac0a7ce8aab3e1f) ra > > 0xffffffff814e3110 sp 0x980000000fd97a40, sz 96 > > octciu_intr_bank+0x270 > > (77e060040f88a,247c372c96c2746a,980000000fd97a00,c77a9639b987eb7e) ra > > 0xffffffff814e2814 sp 0x980000000fd97aa0, sz 160 > > octciu_intr0+0x94 > > (77e060040f88a,247c372c96c2746a,b68846e5d34476ee,c77a9639b987eb7e) ra > > 0xffffffff81465648 sp 0x980000000fd97b40, sz 64 > > interrupt+0x170 > > (77e060040f88a,434c3cde35ce707c,b68846e5d34476ee,c77a9639b987eb7e) ra > > 0xffffffff8137ca14 sp 0x980000000fd97b80, sz 64 > > k_intr+0xb4 > > (980000000fd97be8,434c3cde35ce707c,b68846e5d34476ee,ffffffff812ca5a > > c) ra 0x0 sp 0x980000000fd97bc0, sz 0 > > (KERNEL INTERRUPT) > > cpu_idle_cycle_wait+0x4 > > (980000000fd97be8,434c3cde35ce707c,b68846e5d34476ee,ffffffff812ca5ac) ra > > 0xffffffff812b2698 sp 0x980000000fd97d40, sz 0 > > sched_idle+0x388 > > (980000000fd97be8,434c3cde35ce707c,b68846e5d34476ee,ffffffff812ca5ac) ra > > 0xffffffff812ca6dc sp 0x980000000fd97d40, sz 112 > > proc_trampoline+0x1c > > (980000000fd97be8,434c3cde35ce707c,b68846e5d34476ee,ffffffff812ca5ac) ra > > 0x0 sp 0x980000000fd97db0, sz 0 > > User-level: pid 92532 > > > I have a blind shot which may be related, or may be completley unrelated, or > simple wrong. > > It reads that if_cnmac aligns RX packet buffers to CACHELINESIZE and > then stores the saved mbuf * in the word immediately before the aligned > address. > > It reads that we allign mbuf clusters always at 64-byte, so, a cluster > already aligned to 128 bytes makes that write may land outside the > allocated buffer. > > Here, I align the buffer base after reserving space for the back-pointer > so the saved mbuf * always stays within the cluster. > > Here a diff where I respect CACHELINESIZE align in mbuf. > > Thoughts? Tests? OKs?
I don't think this is right. First, the alignment logic in cnmac_mbuf_alloc() should align the packet buffer and the mbuf pointer correctly even if the mbuf cluster was only 8-byte aligned (in practice the 2k cluster pool should return 2k-aligned clusters). The first (partial) cache line in the cluster is used for the mbuf pointer. The cluster's remaining (complete) 15 cache lines are used for packet data (this is the buffer from the hardware's point of view). Second, the skip parameters are only valid for reserving headroom to be used after packet reception. After reception, the bytes in the buffer that do not contain packet data are unpredictable. This is why the mbuf pointer has to be put outside the hardware buffer. The buffering logic in the cnmac(4) driver has been more or less unchanged for nearly a decade and has worked reliably as far as I know. Maybe some relatively new code adjustment somewhere has uncovered a bug in octeon or mips64 specific code and is now causing problems with Klemens' combination of things. > Index: sys/arch/octeon/dev/if_cnmac.c > =================================================================== > RCS file: /home/cvs/src/sys/arch/octeon/dev/if_cnmac.c,v > diff -u -p -r1.86 if_cnmac.c > --- sys/arch/octeon/dev/if_cnmac.c 20 May 2024 23:13:33 -0000 1.86 > +++ sys/arch/octeon/dev/if_cnmac.c 4 Apr 2026 00:11:27 -0000 > @@ -356,8 +356,8 @@ cnmac_ipd_init(struct cnmac_softc *sc) > > ipd_aa.aa_port = sc->sc_port; > ipd_aa.aa_regt = sc->sc_regt; > - ipd_aa.aa_first_mbuff_skip = 0/* XXX */; > - ipd_aa.aa_not_first_mbuff_skip = 0/* XXX */; > + ipd_aa.aa_first_mbuff_skip = CACHELINESIZE; > + ipd_aa.aa_not_first_mbuff_skip = CACHELINESIZE; > cn30xxipd_init(&ipd_aa, &sc->sc_ipd); > } > > > > -- > wbr, Kirill >
