From owner-freebsd-current@FreeBSD.ORG Mon Jun 6 03:20:26 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E30D316A41C for ; Mon, 6 Jun 2005 03:20:26 +0000 (GMT) (envelope-from oberman@es.net) Received: from postal2.es.net (postal2.es.net [198.128.3.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id C10E543D1D for ; Mon, 6 Jun 2005 03:20:26 +0000 (GMT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal2.es.net (Postal Node 2) with ESMTP (SSL) id IBA74465 for ; Sun, 05 Jun 2005 20:20:26 -0700 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id CC7A35D08 for ; Sun, 5 Jun 2005 20:20:25 -0700 (PDT) To: current@freebsd.org Date: Sun, 05 Jun 2005 20:20:25 -0700 From: "Kevin Oberman" Message-Id: <20050606032025.CC7A35D08@ptavv.es.net> Cc: Subject: Livelock seen on current with threaded processes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2005 03:20:27 -0000 I am running current on an IBM T30 with P4m CPU@1.8 GHz and 512 MB. ATA100 disk (5400 RPM). When I run some threaded codes, I see the system response slow badly. I've tried 4BSD, ULE, and PREEMPTION without seeing any real difference. For a long time I was unable to repeat the problem reliably, but now I have an easy way to do it. I run transcode on a video file to convert it to divx4 using the xvid4 library. I do this with nice set to 10 and top confirms that it is set to 10. At various times, the system starts locking up. Windows won't refresh. Shell commands never execute (nor do keys echo) in some windows including syscons vtys. If my gkrellm is still alive (and it usually is), I see the system at 97% CPU and nothing else busy. There is a bit a disk I/O but not much. If I wait until the transcode operation completes, the system quickly returns to normal. This effectively precludes doing anything on the system while transcode is running which is a real pain since it typically transcodes at only about 5 framed per second and takes a long time to transcode 5 minute video clips. Has anyone else seen this? There was a recent thread on some similar problems on stable, but I can't say if they are really the same. Since nice does not seem to help, I am really suspicious it's a threading issue of some sort, but I am far from sure. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634