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
[EMAIL PROTECTED]
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
