Ken Nakata <kenn@synap.ne.jp> wrote:

>panic: pool_get: ffsinopl: page empty
>Stopped in fsck at	_Debugger+0x6:  unlk    a6
>db> t
>_Debugger(...) + 6
>_panic(...) + 52
>_pool_get(...) + 114
>_ffs_vget(...) + 90
>_ufs_lookup(...) + a32
>_lookup(...) + 21c
>_namei(...) + 2e2
>_sys___stat13(...) + 2a
>_syscall(...) + 11c
>_trap0() + e
>db> _
>
>Has anybody seen this? (admittedly, I haven't been paying much
>attention to traffic on this list... )-:

Yes, this looks almost identical to some of the panics I've been seeing, 
and this one is in fact identical to one I have experienced. Others have 
reported seeing this when they try to access a second disk or when they 
try and run fsck on a disk at startup. I've also been able to reproduce 
it by running a certain combination and sequence of userland applications 
right after bringing the system up.  The problem has been occuring in 
prior versions of the kernel -- I can reproduce it with a stock 1.3.2 
kernel, others have seen it in kernels dating back to 0.9. Some systems 
and disk combinations are more sensitive to the problem than others and 
the problem typically displays different footprints depending on when it 
pops up.  This leads some of us to suspect that portions of the kernel 
are getting stepped on and that damage isn't always immediately obvious. 
It may be that everybody is being affected but most don't see it since 
it's a non-critical section of kernel memory on their system 
configuration that gets munged.  Since it seems to occur in a somewhat 
random fashion, many of us suspect a rouge I/O interrupt that's not being 
fielded properly.

At any rate the problem seems to be infecting more and more user's 
systems.  Let's hope this is good news as it should aid in finding and 
fixing the problem.

-bob