My home machine repeatedly panics if I kick into swap, which is
a file rather than a partition.  I've been trying to debug it,
and here's my setup:
  - GENERIC kernel, but with POOL_DIAGNOSTIC enabled, from
    -current from around March 11.
  - It's an i386 box (AMD K6).
  - in single-user, create a 20mb file in /, and enable it for
    swap.
  - My machine has 48MB, so if I try to build a kernel with all
    symbols, the ld process is enough to kick it into swap in
    single-user.
    
  After a few seconds of swapping, the machine panics with
"free list modified".  I've got 50 backtraces if anyone wants
to see them.

  Question #1:  Does anyone else use swap-on-file-only, and see
panics under pressure?

  While trying to debug this myself, I've stumbled across a few
things in subr_pool.c that don't make sense.

  Question #2:  In the pool_print1() function, should modif
really be ++'d twice in each iteration of the loop (once in the
assignment to c, and again at the bottom of the loop)?  I tried
passing "lp", and the code as-is will ignore the "p" part of
that.

  After many hours and many dumps, it appears that two calls to
pool_get() are returning the same item.

  Question #3:  What about, when we do a get, we set the magic to
PI_MAGIC+1 (or anything besides PI_MAGIC)?  That way, if a
second get is performed that returns the same item, the "free
list modified" check will notice the duplicate get, since the
magic isn't set to the "I'm free" PI_MAGIC value.  This could be
enabled only in POOL_DIAGNOSTIC mode or whatever.  Currently, it
isn't noticed, and the kernel happily goes forth until the two
pointers end up causing corruption and panics.

  Question #4:  Similarly, in pool_put(), if the put'd object has
its magic already set to PI_MAGIC, it _could_ be a duplicate
put.  We could warn (but not panic) if this occurs, in
POOL_DIAGNOSTIC mode.

  I've been short on kernel debugging time for a while, but I'll
try to continue digging when I can!

  Puzzled,
  Brian
--
Brian Grayson