Re: octeon: cnmac: KERNEL_INTERRUPT drops into ddb

On Sun, 05 Apr 2026 08:19:09 +0200,
Visa Hankala <[email protected]> wrote:
> 
> 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.
> 

Thanks for explanation. I'd like to withdraw this diff.

After carefully reading of allocation part:

		m->m_data = (void *)(((vaddr_t)m->m_data + CACHELINESIZE) &
		    ~(CACHELINESIZE - 1));
		((struct mbuf **)m->m_data)[-1] = m;

and actuall user parts:

		pktbuf = (addr & ~(CACHELINESIZE - 1)) - back * CACHELINESIZE;

I don't think here any issue at all, it was clearly my missreading.

Sorry for the noise.

> > 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
> > 

-- 
wbr, Kirill