On Thu, Aug 25, 2011 at 11:16 PM, Charlie Martin <crmar...@sgi.com> wrote: > We're having a crash in some internal code running on FreeBSD 7.2 > (specifically 7.2-PRERELEASE FreeBSD 7.2-PRERELEASE and yeah, I know it's > quite a bit behind) in which after 18-30 hours of running load tests, the > code panics with: > > panic: Bad link elm 0xffffff0044c09600 next->prev != elm > cpuid = 0 > KDB: stack backtrace: > db_trace_self_wrapper() at 0xffffffff8019119a = db_trace_self_wrapper+0x2a > panic() at 0xffffffff80307c72 = panic+0x182 > devfs_populate_loop() at 0xffffffff802a43a8 = devfs_populate_loop+0x548 > > > First question: where's the most appropriate place to ask about this kind of > bug on a back version.
Probably -stable. I don't know how many developers are still running 7. Most are on 8 at this point. > Second: does this remind anyone of any bugs? Googling came up with a few > somewhat similar things but hasn't provided much insight so far. This panic is very common when list updates aren't adequately serialized. > Third: I tried compiling with the sys/queue.h QUEUE_MACRO_DEBUG defined in > order to get more useful information from the panic. The kernel build fails > in pmap.c when this macro is defined, giving an error saying the CTASSERT > macro is resolving to a negative array size. Is there any particular secret > to using this macro (like, no one goes there any more?) This is because you are running amd64 and the the pv_entry constants were defined assuming the default (smaller) list entry structure. I once fixed this in a local tree, but I think I was so dismayed at the "obviousness" of the bug I was tracking down that I neglected to commit the pmap update. It shouldn't be too hard to calculate the correct constants. Cheers _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
