> Did yours include the misaligned access in sbdrop()? That's a kernel error
> by definition. (The pool_get() panic is probably just a spurious secondary
> effect.)

Sorry, don't recall. If it happens again I'll see what I can type in.
There's not much to read because of that blasted huge default console font.
(I only have 640x480 monitors to spare for my multias...)

> With all the (icache-busting-they-probably-slow-you-down) macros, and with
> gdb's very poor disassembly, it's really hard to tell which source line
> faulted. On a kernel here, gdb reports line 757, which is the closing brace
> of the first while-loop.

Debugging through macros is painful in general. Last I recall MULTI didn't
give you much help there either.

Not sure what you mean by poor disassembly though... care to elaborate?

> It would really be nice if there was a way to reproduce this. One possibility
> is to instrument sbdrop() and the macros it calls; this might produce an
> instrumented panic even on i386, which won't trap on its own.

Mmm. Well, I will do what I can to exercise the machines. Erik just loaned me
a drive-less multia and a spare case to replace the power supply that you told
me was about to die -- well guess what, last week it died.

I do have a set of exportable tarballs that are a bit messy (the source tgz
files have .o's in them...) but should suffice to upgrade someone who wants to
help test this. That was what the multia was trying to upload when it croaked.

Todd Whitesel
toddpw @ best.com