From owner-freebsd-stable@FreeBSD.ORG Tue Feb 27 21:17:19 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5A7D316A405 for ; Tue, 27 Feb 2007 21:17:19 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id CA9ED13C4B4 for ; Tue, 27 Feb 2007 21:17:18 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.14.0/8.14.0/NETPLEX) with ESMTP id l1RKoKkG004561; Tue, 27 Feb 2007 15:50:20 -0500 (EST) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-3.0 (mail.ntplx.net [204.213.176.10]); Tue, 27 Feb 2007 15:50:20 -0500 (EST) Date: Tue, 27 Feb 2007 15:50:20 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Dimuthu Parussalla In-Reply-To: <001d01c75aad$1ceb4050$d801a8c0@dimuthu> Message-ID: References: <001d01c75aad$1ceb4050$d801a8c0@dimuthu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: 'Martin Blapp' , freebsd-stable@freebsd.org Subject: RE: Clamav-90_2 Lockup with freebsd 6.2 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Feb 2007 21:17:19 -0000 On Wed, 28 Feb 2007, Dimuthu Parussalla wrote: > Hi, > > I can confirm the same situation. My dual xeon x236 server runs very high > cpu utilisation with clamav. Also tried with maxthreads to 1. Result is the > same but frequency of locked process seems to be reduced. I think clamav has a bug somewhere. I seem to recall some other application having bad assumptions about sockets, but can't remember exactly what it was. I do know that a close() on a file descriptor does not wakeup and return an error to all threads waiting on it. FreeBSD and supposedly Linux have this behavior, but Solaris will return an error to all threads. I'm not sure this has anything to do with it, but after seeing the bug report of clamd having a lot of threads waiting in accept(), it might be a place to start investigating... -- DE