From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 2 10:48:16 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9B58C16A41F; Mon, 2 Jan 2006 10:48:16 +0000 (GMT) (envelope-from a.pirko@inode.at) Received: from smartmx-07.inode.at (smartmx-07.inode.at [213.229.60.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0E44B43D62; Mon, 2 Jan 2006 10:48:14 +0000 (GMT) (envelope-from a.pirko@inode.at) Received: from [85.124.28.145] (port=63566 helo=[192.168.1.11]) by smartmx-07.inode.at with esmtp (Exim 4.50) id 1EtNEb-0005DC-Br; Mon, 02 Jan 2006 11:48:13 +0100 Message-ID: <43B904EC.8010700@inode.at> Date: Mon, 02 Jan 2006 11:48:12 +0100 From: Armin Pirkovitsch User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051204) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Watson References: <43B6C134.6060802@inode.at> <20060101163522.Y74401@fledge.watson.org> <43B85C33.90000@inode.at> <20060102060259.X2892@fledge.watson.org> In-Reply-To: <20060102060259.X2892@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: Deadlock FreeBSD 6 / 7 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: Mon, 02 Jan 2006 10:48:16 -0000 Robert Watson wrote: > > On Sun, 1 Jan 2006, Armin Pirkovitsch wrote: > >> Robert Watson wrote: >> >>>> I guess one of those parts creates the trouble, but I have no idea >>>> how to trace it... Is there a way to run the whole thing in some >>>> kind of debugger? Or is there a diffrent way to locate the problem? >>> >>> >>> The usual first step to debug a deadlock, if WITNESS or INVARIANTS >>> doesn't trigger dropping you into the debugger, is to break into the >>> debugger using a console or serial break. To do this, you need to >>> compile: >> >> >> I added options BREAK_TO_DEBUGGER and used make buildkernel and make >> installkernel.debug and was not able to reconstruct the crash. I guess >> the debug stuff slowed it down enough to not come to the bug... (even >> installworld worked fine, which usually kills it) So this is what I >> feared - the debug stuff changes the timing by slowing it down which >> makes it pretty hard to reconstruct the crash... Is there any other >> way? (btw. it's a notebook, so there is no old serial bus) > > > Try compiling in only options DDB and BREAK_TO_DEBUGGER. Even without > the fully debugging features on, it may be enough to give us some > initial insight into the source of the problem. without installkernel.debug (just installkernel) I was able to reconstruct the crash, but again was not able to enter the debugger. > Does your notebook have firewire support? Yes it has and one my other machines has too if that is any help? -- Armin Pirkovitsch a.pirko@inode.at