From owner-freebsd-questions@FreeBSD.ORG Sat Mar 7 07:49:37 2009 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 02767106564A for ; Sat, 7 Mar 2009 07:49:37 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from mx02.qsc.de (mx02.qsc.de [213.148.130.14]) by mx1.freebsd.org (Postfix) with ESMTP id B60B88FC1C for ; Sat, 7 Mar 2009 07:49:36 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from r55.edvax.de (port-92-196-109-64.dynamic.qsc.de [92.196.109.64]) by mx02.qsc.de (Postfix) with ESMTP id 1EDA316C0105; Sat, 7 Mar 2009 08:49:34 +0100 (CET) Received: from r55.edvax.de (localhost [127.0.0.1]) by r55.edvax.de (8.14.2/8.14.2) with SMTP id n277nRsv010392; Sat, 7 Mar 2009 08:49:28 +0100 (CET) (envelope-from freebsd@edvax.de) Date: Sat, 7 Mar 2009 08:49:27 +0100 From: Polytropon To: Giorgos Keramidas Message-Id: <20090307084927.72c9cb0c.freebsd@edvax.de> In-Reply-To: <87bpsdkdv3.fsf@kobe.laptop> References: <20090307074423.640ec208.freebsd@edvax.de> <87bpsdkdv3.fsf@kobe.laptop> Organization: EDVAX X-Mailer: Sylpheed 2.4.7 (GTK+ 2.12.1; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: FreeBSD Questions Subject: Re: Status field STATE in top(1) interactive mode X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Polytropon List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2009 07:49:37 -0000 On Sat, 07 Mar 2009 09:10:08 +0200, Giorgos Keramidas 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, ...