Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 7 Mar 2009 08:49:27 +0100
From:      Polytropon <freebsd@edvax.de>
To:        Giorgos Keramidas <keramida@ceid.upatras.gr>
Cc:        FreeBSD Questions <freebsd-questions@freebsd.org>
Subject:   Re: Status field STATE in top(1) interactive mode
Message-ID:  <20090307084927.72c9cb0c.freebsd@edvax.de>
In-Reply-To: <87bpsdkdv3.fsf@kobe.laptop>
References:  <20090307074423.640ec208.freebsd@edvax.de> <87bpsdkdv3.fsf@kobe.laptop>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 07 Mar 2009 09:10:08 +0200, Giorgos Keramidas <keramida@ceid.upatras.gr> wrote:
> "umtx lock", "umtx", "umtxn", "umtxpi" and "umtxpp" are internal kernel
> strings that are used to identify particular locks and wait conditions
> where a process may block while running inside the kernel. 

Okay, this makes things more clear to me.



> A recent FreeBSD 8.0-CURRENT kernel shows: [...]

Having a look at various source files makes me believe that the
problem described has something to do with memory access of Opera
"through" the kernel (mutex -> mtx). It furthermore explains the
"hanging" - a sleep command in the kernel.

For the "uncond" state, I found nothing as informative as the
above. Maybe it's a "don't know" placeholder. :-)

 PID USERNAME    THR PRI NICE   SIZE    RES STATE    TIME   WCPU COMMAND
9774 poly          3 101    0   145M   115M ucond    0:00 11.08% opera

Furthermore, I think top(1) gets the text for the locks from
somewhere else, they're not part of the top(1) sources. At
least, /usr/src/usr.bin/top is very dry and doesn't contain
much more when in /usr/obj. :-) 



-- 
Polytropon
>From Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090307084927.72c9cb0c.freebsd>