From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mika.eatserver.nl (mika.eatserver.nl [195.20.9.75]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 85CCFB7124 for ; Tue, 9 Nov 2010 21:23:43 +1100 (EST) Message-ID: <4CD918C2.4090400@aimvalley.nl> Date: Tue, 09 Nov 2010 10:47:46 +0100 From: Norbert van Bolhuis MIME-Version: 1.0 To: Joakim Tjernlund Subject: Re: INFO: task snmpd:398 blocked for more than 120 seconds. References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Cc: linuxppc-dev@ozlabs.org, David Laight List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Joakim Tjernlund wrote: >>> I can't make out what is causing this hang every now an then: >>> >>> INFO: task snmpd:398 blocked for more than 120 seconds. >> My problem with that 'error' message is that there is no way >> for a driver to disable it on a per-process basis. >> We have some processes whose 'normal state' is to sleep >> uninterruptibly in the kernel. Shutdown is handled by >> an explicit request (not by sending a signal). >> The processes could be kernel worker threads (except that >> is is ~impossible to handle them exiting from a loadble >> kernel module) so are actually children of a daemon sat >> inside an ioctl() request that never terminates! >> >> However, on the face of it, your case does look as though >> the mutex is fubar'ed. >> >> Might be worth (somehow) dumping the mutex state. > > ehh, it is locked, isn't it? How to find who locked it > and forgot to release it? > You could add show_state to check_hung_task It worked for me while solving some (application) task hangups. --- N. van Bolhuis.