DragonFly bugs List (threaded) for 2008-12
Re: All new processes stuck in "flstik" state
:Most of the time when I see processes in flstik state, the machine recovers,
:but have managed to find how to reproduce the situation, where all new
:processes get stuck in flstik state (even ssh-ing into the machine creates a
:new sshd process which gets stuck in flstik state and won't continue, can't
:login locally, etc.).
:The machine has /boot UFS and / hammer with several PFS' (done using
:the /usr/share/examples/rconfig/hammer.sh, but my /var/tmp isn't a PFS, but a
:softlink to /tmp).
:If I run http://pastebin.ca/1279548 (with http://pastebin.ca/1279549 as the
:pkgsrc.img.label) 2, sometimes 3 times, all new processes get stuck in flstik
:state during installworld.
:Panicked the machine and uploaded the cores (the first time it happened i
:panicked the machine and made the memory dumps and after succesfully
:reproducing the situation i did it again) to
I'm guessing that the problem is due to running HAMMER on the VN
backed by a file on another HAMMER filesystem.
The kgdb on leaf is unable to list the threads in your dump, probably
due to structural mismatches. Could you do it on your box and post a
backtrace of the threads stuck in flstik? I am going to guess that
the bd_wait() they are stuck in is deep inside VN, probably the
You 'kgdb kernel.1 vmcore.1' and do an 'info thread'. The threads
we are interested in are for threads 0xd8fa2000, 0xd8fa2600,
0xd8fb5300, 0xdce45400, 0xd8fb4800, and 0xdce46d00. For each one
find the thread number and do 'thread <number>' and 'back' (abbreviation
If that is the problem the solution is really simple, I can just
pass a flag in the VOP_WRITE to tell HAMMER not to call bwillwrite().