On Tue, Dec 24, 2024 at 12:29 AM Martin Pieuchot <m...@grenadille.net> wrote: > Thanks for the report. Do I understand correctly that George's change > is not the fix we're looking for your bug?
Correct, the collection of recent changes has not eliminated kernel panics under load on my two TalosII machines. If it is helpful to anyone, I'm happy to give a few more ddb commands in the current panic state. Otherwise, I'll step back from the current messy bug report and try to pin things down more clearly on my machines and return when I can give a better bug report. > > [...] > > r1|Stopped at _rb_remove+0x36c: ld r4,8(r3) > > TID PID UID PRFLAGS PFLAGS CPU COMMAND > > *453813 7858 8889 0x2000002 0 3 compile > > 36553 81731 8889 0x2000002 0 2 compile > > 99640 86457 8889 0x2000002 0 7 compile > > 242134 64462 8889 0x2000002 0 0 compile > > 68242 72226 8889 0x2000002 0x4000000 4 go > > 495275 4590 8889 0x2000002 0x4000000 1 compile > > 250285 66963 0 0x14000 0x200 6 reaper > > 241654 98481 0 0x14000 0x200 5 pagedaemon > > What is 'compile'? What are you compiling to trigger the bug? Ah, yes, I see my wording was ambiguous. This is from a kernel built from current sources via AnonCVS with option WITNESS. The panic only happens under load; in this case, the load is from running as the Go Builder for openbsd/powerpc64 and the compiles you see are from the LUCI CI infrastructure the Go team uses for testing their changes on OpenBSD. But usually I can produce a panic independent of Go, just compiling /usr/src with make -j24.
