In case there's the slightest chance that anyone cares...  It looks
like this was because I had "options DIAGNOSTIC" in my kernel.  I have
had a current kernel up without DIAGNOSTIC for almost a week now --
and beating on it really hard sometimes -- back to the rock solid
stability I'm used to.  (And, yes, I did have DIAGNOSTIC in because I
was playing around inside the kernel -- I didn't do it just because it
sounded like a k3vv1 option.)

But, this raises a question: do panics in the kernel, with DIAGNOSTIC
turned on, still signal a potential bug?  I'm thinking kind of
anologeous to warnings emitted from a C compiler.  In other words: in
a kernel where all known "warnings" were "fixed", should it be
expected that this kernel would never panic if DIAGNOSTIC was built
in?

>With a kernel built 6/18 from sources supped 6/17 or 6/18, I've
>recently been getting this panic every few days or so:
>
>panic: ffs_alloccg: map corrupted
>stopped at _Debugger+0x4: movl %ebp,%esp
>
>trace reveals:
>_Debugger...
>_panic...
>_ffs_vfree(f8..., f9..., 7b0, 8, 4000) at _ffs_vfree+0x3f5
>_ffs_blkpref(f8..., f9..., 24e70, 0, f8...) at _ffs_blkpref+0xd3f
>_ffs_blkpref(f8..., 25, 24e70, 4000, 0) at _ffs_blkpref+0x72b
>_ffs_blkpref(f8..., 25, 24e70, 4000, f8...) at _ffs_blkpref+0x257
>_ffs_realloccg(f8..., 1, 24e70, 1000, 1800) at _ffs_realloccg+0x3aa
>_ffs_balloc(f8..., 1, 1200, f8..., f9...) at _ffs_balloc+0x31d
>_ffs_write(f9..., 800, f9..., f8..., 13) at _ffs_write+0x297
>_vn_write(f8..., f9..., f8...) at _vn_write+0xd0
>_sys_write(f8..., f9..., f9..., 0, 800) at _sys_write+0xb1
>_syscall() at _syscall+0x287
>--- syscall (number 4) ---
>0x3b4bb:
>
>The few times I've seen it the sequence of functions in the middle
>isn't always exactly the same, but the top and bottom are always the
>same.  Does this sound like anything anyone else has seen?  Or sound
>like anything someone might have fixed between then and now?
>
>I'm going to try to build a current kernel as soon as I can get one to
>compile.  However, I'm not 100% convinced that it's even NetBSD's
>fault.  A *lot* of things have changed in my system over the last
>month or so (upgraded my 5v AMD 486DX2/80 with a 3v AMD 5x86/133,
>upgraded my ATI 8514/Ultra (Mach8) ISA + ATI VGA Basic ISA to a VLB
>ATI Mach32, upgraded my X server, libraries and binaries from 3.1.2 to
>beta 3.1.2D/E).  Although I have tried to upgrade one thing at a time,
>and haven't seen any obvious instabilities from any of the individual
>changes (except for a Mach32 bug in the stock 3.1.2 server, which is
>why I upgraded it).  But, I'd really like to hear if this sounds
>familiar to anyone else before I start yanking my system apart *again*
>trying to isolate the problem.

-----------------------------------------------------------------------------
  Michael L. VanLoon                                 michaelv@HeadCandy.com
        --<  Free your mind and your machine -- NetBSD free un*x  >--
    NetBSD working ports: 386+PC, Mac 68k, Amiga, Atari 68k, HP300, Sun3,
        Sun4/4c/4m, DEC MIPS, DEC Alpha, PC532, VAX, MVME68k, arm32...
    NetBSD ports in progress: PICA, others...

   Roll your own Internet access -- Seattle People's Internet cooperative.
                  If you're in the Seattle area, ask me how.
-----------------------------------------------------------------------------