Deadlock FreeBSD 6 / 7

[Armin Pirkovitsch]

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 at inode.at