17.01.2026 23:47, Miod Vallat пишет:
>> Every now and then my router sits in ddb due to this,
>> requiring manual reboot (no panic, so ddb.panic=0 does not help).
>
> No message prior entering ddb?
Console wasn't connected at that time, the the ddb prompt whas
the first i saw after attaching and hitting enter.
>
>> cnmac_recv_mbuf+0x134 (77e060040f88a,1,980000000fd97a00,980000000fd979fc)
>> ra 0xffffffff8132c9fc sp 0x980000000fd979d0, sz 32
>
> This looks like the call to panic() on line 1147 of
> sys/arch/octeon/dev/if_cnmac.c.
1137 m0 = mprev = NULL;
1138 total = left = (word1 & PIP_WQE_WORD1_LEN) >> 48;
1139 for (i = 0; i < nbufs; i++) {
1140 addr = word3 & PIP_WQE_WORD3_ADDR;
1141 back = (word3 & PIP_WQE_WORD3_BACK) >>
PIP_WQE_WORD3_BACK_SHIFT;
1142 pktbuf = (addr & ~(CACHELINESIZE - 1)) - back *
CACHELINESIZE;
1143 pm = (struct mbuf **)PHYS_TO_XKPHYS(pktbuf, CCA_CACHED) -
1;
1144 m = *pm;
1145 *pm = NULL;
1146 if ((paddr_t)m->m_pkthdr.ph_cookie != pktbuf)
1147 panic("%s: packet pool is corrupted, mbuf cookie
%p != "
1148 "pktbuf %p", __func__, m->m_pkthdr.ph_cookie,
1149 (void *)pktbuf);
1150
1151 /*
1152 * Because of a hardware bug in some Octeon models the size
1153 * field of word3 can be wrong (erratum PKI-100).
1154 * However, the hardware uses all space in a buffer before
1155 * moving to the next one so it is possible to derive
1156 * the size of this data segment from the size
1157 * of packet data buffers.
1158 */
1159 size = OCTEON_POOL_SIZE_PKT - (addr - pktbuf);
1160 if (size > left)
1161 size = left;
Odd given 'show panic' said "the kernel did not panic" and ddb.panic=0 did not
kick in.
On the other hand, "%s: packet pool is corrupted, mbuf cookie %p != pktbuf %p"
sounds related to "cnmac5: cannot allocate command buffer from free pool
allocator"
I reported to bugs@ earlier. Could this be related due to the uvm changes?
Just hit it again... third time today, as if it got worse:
cnmac_recv_mbuf+0x134 (77e060040f88a,1,98000000242bfe10,98000000242bfe0c) ra
0xffffffff8132c9fc sp 0x98000000242bfde0, sz 32
cnmac_recv+0x7c (77e060040f88a,1,98000000242bfe10,f81267b1ca5a6cd4) ra
0xffffffff8132aa2c sp 0x98000000242bfe00, sz 80
cnmac_intr+0xfc
(77e060040f88a,4d411df681f0fe65,98000000242bfe10,f81267b1ca5a6cd4) ra
0xffffffff814e3110 sp 0x98000000242bfe50, sz 96
octciu_intr_bank+0x270
(77e060040f88a,4d411df681f0fe65,98000000242bfe10,4a2c270c96f57e95) ra
0xffffffff814e2814 sp 0x98000000242bfeb0, sz 160
octciu_intr0+0x94
(77e060040f88a,4d411df681f0fe65,4560ca232182e387,4a2c270c96f57e95) ra
0xffffffff81465648 sp 0x98000000242bff50, sz 64
interrupt+0x170
(77e060040f88a,b15ea342f33579be,4560ca232182e387,4a2c270c96f57e95) ra
0xffffffff8137cb48 sp 0x98000000242bff90, sz 64
u_intr+0xb8 (98000000242bc000,b15ea342f33579be,4560ca232182e387,3dadad9450) ra
0x0 sp 0x98000000242bffd0, sz 0
User-level: pid 90410
...
*90410 246744 91772 0 7 0x2 ruby34
...
Not connect either, sorry; setting up a permanent cu session soon.
This time it sysupgraded to
OpenBSD 7.8-current (GENERIC.MP) #124: Wed Jan 14 11:01:22 MST 2026
[email protected]:/usr/src/sys/arch/octeon/compile/GENERIC.MP
Can't back it up with dates or logs, but I'm very certain that none of that ever
happened before I went from 7.8-release (or -beta perhaps) to snapshots,
otherwise I'd have mailed earlier. Back then the box just worked for
weeks/months.
