Date: Sun, 01 Jan 2006 23:48:19 +0100 From: Armin Pirkovitsch <a.pirko@inode.at> To: Robert Watson <rwatson@FreeBSD.org> Cc: freebsd-hackers@freebsd.org Subject: Re: Deadlock FreeBSD 6 / 7 Message-ID: <43B85C33.90000@inode.at> In-Reply-To: <20060101163522.Y74401@fledge.watson.org> References: <43B6C134.6060802@inode.at> <20060101163522.Y74401@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Robert Watson wrote: > > On Sat, 31 Dec 2005, Armin Pirkovitsch wrote: > >> I have some troubles with my notebook and any version of FreeBSD >> (starting with 6 since my sata controller wasn't supported earlier). >> It looks like as it would end up in a deadlock which means i have no >> access to the debugger nor to any other kind of tracing methods. Even >> with KTR, WITTNESS and DIAGNOSTIC enabled in the kerenl I get no >> message what went wrong or what might have caused the trouble. These >> fullstops always turn up when i compile and install programs (or >> sometimes during the installation of FreeBSD itself) Hardware: Intel >> Pentium-M 760 (Centrino, 2GHz) VIA VT 6421 SATA Controller 80GB >> Samsung SATA HD >> >> 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: > > options BREAK_TO_DEBUGGER > options DDB > > into your kernel. On syscons (not in X11), you can hit Ctrl-Alt-Escape > to try to get to the debugger, or send a serial break. The serial break > is often more reliable, and the nice thing about running DDB on a serial > console from a second machine is that you can easily copy/paste debug > output. Once you're in the debugger, you can list the threads, locks > held, trace stacks, and so on. > > If you can't get into the debugger using a serial break, then usually > the next thing you have to try is using an NMI. Unfortunately, most > hardware doesn't ship with an NMI button, although some server hardware > vendors now provide them. In the vast majority of cases, a serial break > will get to the debugger, and in many cases, so will a console break. 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) -- Armin Pirkovitsch a.pirko@inode.at
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?43B85C33.90000>