From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 11 13:38:31 2009 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 B58D0106566C for ; Sat, 11 Apr 2009 13:38:31 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-fx0-f167.google.com (mail-fx0-f167.google.com [209.85.220.167]) by mx1.freebsd.org (Postfix) with ESMTP id 142AC8FC13 for ; Sat, 11 Apr 2009 13:38:30 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: by fxm11 with SMTP id 11so1428378fxm.43 for ; Sat, 11 Apr 2009 06:38:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:to:subject:references :organization:from:date:in-reply-to:message-id:user-agent :mime-version:content-type; bh=nrz/awDTk874KbpP3wv9uQNdPzGqx92E5tSr6EuZEIk=; b=YYPdP2kU16AWRSp+p+lzW42GIzlzWaan/2OIwUeDktGU6s0NTkfxCe/jf8YIOKIIHv dGqloI2KAosNTcy0RBDlVDIAEwzUYiGPEipZ9N2I+wuLNeXhrGWFBccsiNnDXxDXiree BqypGc2d54XzAuJrFvoJNJORXaH6dq43Kan5Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=to:subject:references:organization:from:date:in-reply-to:message-id :user-agent:mime-version:content-type; b=lRVo6ZOhB15yj1AzKDQKmu9kI4ilWsO2hD20Bnwu7VxO+ZmMAoHx8LCsSTaFmx9DnU pcSZRd6/VXobg1ktYhESms5paHyrblReRVLRnhokROf5EjzrcgajYPD2/3c5kDOVGLTr dvquG7nz7ewrmcMuaZyvNlyGcB/LElKigyA4g= Received: by 10.103.213.19 with SMTP id p19mr2348613muq.9.1239455567639; Sat, 11 Apr 2009 06:12:47 -0700 (PDT) Received: from localhost (vpn-195-69-246-114.customer.onet.com.ua [195.69.246.114]) by mx.google.com with ESMTPS id j6sm5302513mue.4.2009.04.11.06.12.46 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 11 Apr 2009 06:12:46 -0700 (PDT) To: xorquewasp@googlemail.com, freebsd-hackers@freebsd.org References: <20090410132354.GA20721@logik.internal.network> <20090410154251.GA49384@logik.internal.network> <1239385368.1922.74.camel@balrog.2hip.net> <20090410175922.GA50520@logik.internal.network> <1239388293.1922.80.camel@balrog.2hip.net> <20090410211307.GA83697@logik.internal.network> <3a142e750904101730k53b7fbabn6e801ac36f1182e0@mail.gmail.com> <20090411101559.GC83697@logik.internal.network> Organization: TOA Ukraine From: Mikolaj Golub Date: Sat, 11 Apr 2009 16:12:45 +0300 In-Reply-To: <20090411101559.GC83697@logik.internal.network> (xorquewasp@googlemail.com's message of "Sat\, 11 Apr 2009 11\:15\:59 +0100") Message-ID: <86zlen9vw2.fsf@kopusha.onet> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Subject: Re: diagnosing freezes (DRI?) 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: Sat, 11 Apr 2009 13:38:32 -0000 On Sat, 11 Apr 2009 11:15:59 +0100 xorquewasp@googlemail.com wrote: x> On 2009-04-11 02:30:40, Paul B. Mahol wrote: >> >> If it locks under X11 then use debug.debugger_on_panic=0 sysctl. >> Not doing this will increase drasticaly chances of locking whole system >> and not providing any debug data. x> I don't seem to have that sysctl. You will see this sysctl only if you build your kernel with ddb(4) support. If you are interested in providing useful information about your freezes, please read the following: http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html You need to build your kernel with options described in http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-online-ddb.html and http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-deadlocks.html As you run X, you need to have debug.debugger_on_panic=0 set (as Paul has suggested). Otherwise ddb would enter on panic but you wouldn't be able to access it due to X. After panic you will be able to get useful information from generated core dump using kgdb. Another option is to set debug.debugger_on_panic=1 but also set some ddb script that will run when the kernel debugger is entered as a result of a panic. This script will enable output capture, dump some useful debugging info to capture buffer, and then force a kernel dump to be written out followed by a reboot. E.g. running something like this will do the trick: ddb script 'kdb.enter.panic=capture on; show pcpu; show allpcpu; bt; ps; show locks; show alllocks; show lockedvnods; alltrace; call doadump; reset' After reboot you can extract captured information from the capture buffer information using the command: ddb capture -M /var/crash/vmcore.X print > ddb.out You need to increase the value of debug.ddb.capture.bufsize sysctl variable to make sure all ddb output will be captured. You can read more about this in ddb(4), ddb(8), textdump(4). -- Mikolaj Golub