From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 28 21:50:17 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 04C9F106566B for ; Tue, 28 Jun 2011 21:50:17 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [IPv6:2607:f678:1010::34]) by mx1.freebsd.org (Postfix) with ESMTP id B1CFB8FC08 for ; Tue, 28 Jun 2011 21:50:16 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id p5SLoEh6043544 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 28 Jun 2011 14:50:15 -0700 (PDT) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id p5SLoEnV043543; Tue, 28 Jun 2011 14:50:14 -0700 (PDT) Received: from fbsd61 by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA20057; Tue, 28 Jun 11 14:47:36 PDT Date: Tue, 28 Jun 2011 14:54:49 -0700 From: perryh@pluto.rain.com To: yuri@rawbw.com Message-Id: <4e0a4da9.2zgU/lbkfArgyq8o%perryh@pluto.rain.com> References: <4E0A201D.9000601@rawbw.com> In-Reply-To: <4E0A201D.9000601@rawbw.com> User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: How can process in STOP state consume 200% CPU? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 21:50:17 -0000 Yuri wrote: > kill -9 doesn't kill it. I think I've seen this before; it looks as if, since the process is STOPped, the "kill -9" remains pending rather than being acted upon. I _think_ you can make the process go away by doing a "kill -CONT" after the "kill -9". No idea how a STOPped process can continue to consume CPU, unless in an infinite loop at elevated interupt level (and in that case the "kill -CONT" may not work -- you may need to drop into kdb, try to do some debugging and/or get a dump, and then reboot).