Re: All new processes stuck in "flstik" state

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

: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
:leaf:~rumko/crash/{kernel,vmcore}.{0,1}
:-- 
:Regards,
:Rumko

    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
    path:  VNDEVICE->VOP_WRITE->(HAMMER)->bwillwrite()->bd_wait().

    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
    for backtrace).

    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().

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>