Re: Bogus KASSERT() in LFS?

[Eduardo Horvath <eeh%NetBSD.org@localhost>]

On Wed, 5 Jan 2011, Martin Husemann wrote:

> On Wed, Jan 05, 2011 at 07:35:53PM +0000, Eduardo Horvath wrote:
> > Really?  Last time I tried (about a month or two ago) I wasn't able to 
> > hang LFS.  OTOH, looks like there's been quite some churn since then.  
> > 
> > What's your setup and what tests are you running?
> 
> I run src/tests/fs/vfs/t_full with argument "lfs_fillfs", unfortunately
> gdb doesn't like me:
> 
> (gdb) run lfs_fillfs
> Starting program: /usr/obj/tests/fs/vfs/t_full lfs_fillfs
> Segment size 1048576 is too large; trying smaller sizes.
> WARNING: the log-structured file system is experimental
> WARNING: it may cause system crashes and/or corrupt data
> lfs_cleanerd[5658]: /mnt: attaching cleaner
> lfs_cleanerd[5658]: /mnt: detaching cleaner
> panic: rumpuser fatal failure 11 (Resource deadlock avoided)
> 
> Program received signal SIGABRT, Aborted.
> 0x0000000042a09720 in ?? ()
> (gdb) bt
> #0  0x0000000042a09720 in ?? ()
> #1  0x0000000042a09720 in ?? ()
> Previous frame identical to this frame (corrupt stack?)

Hm.  Interesting.  I've never tried lfs on rump.  I wonder if there are 
issues running both the filesystem and the cleaner as separate userland 
processes.

> On a life kernel this probably would be a "locking against myself". Have
> you tried filling lfs with a LOCKDEBUG kernel recently?

Certainly.  I usually do -j4 kernel builds with LOCKDEBUG, as well as 
other miscellaneous stressers.  

Eduardo