From owner-freebsd-current@FreeBSD.ORG Fri Aug 13 22:52:39 2004 Return-Path: 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 DC04316A4CE for ; Fri, 13 Aug 2004 22:52:39 +0000 (GMT) Received: from ion.gank.org (ion.gank.org [69.55.238.164]) by mx1.FreeBSD.org (Postfix) with ESMTP id ABC2543D46 for ; Fri, 13 Aug 2004 22:52:39 +0000 (GMT) (envelope-from craig@xfoil.gank.org) Received: by ion.gank.org (mail, from userid 1001) id 63E472B4FF; Fri, 13 Aug 2004 17:52:39 -0500 (CDT) Date: Fri, 13 Aug 2004 17:52:37 -0500 From: Craig Boston To: Martin Blapp Message-ID: <20040813225236.GA69675@nowhere> Mail-Followup-To: Craig Boston , Martin Blapp , freebsd-current@freebsd.org References: <20040813121208.M31181@cvs.imp.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040813121208.M31181@cvs.imp.ch> User-Agent: Mutt/1.4.2.1i cc: freebsd-current@freebsd.org Subject: Re: Deadlocks with recent SMP current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Fri, 13 Aug 2004 22:52:40 -0000 On Fri, Aug 13, 2004 at 12:16:57PM +0200, Martin Blapp wrote: > Since yesterday I'm getting complete deadlocks. This time unrelated > the servers are nor loaded at all, the just freeze after a while. > No break into DDB possible at all. Just a "me too", I have an SMP system running 8/5/04 current that hard locks randomly. It seems to happen more often when there is moderate I/O load, such as extracting a tar file or compiling a kernel, but it has happened while almost completely idle too. DDB is in the kernel but cannot be accessed as the system is frozen solid (I do not have NMI capability on this machine). I'm using 4BSD scheduler and get the warning about preemption being disabled. I'm currently running with kern.smp.disabled="1" as that is the only way the system is at all stable :( Oddly enough, it seems to be more responsive without the second processor running than with it -- possibly due to preemption being off. Craig