Re: debugging kernel paniced system
Re: debugging kernel paniced system
- Subject: Re: debugging kernel paniced system
- From: Nikita Danilov <email@hidden>
- Date: Sun, 25 Jul 2004 11:30:41 +0400
Shawn Erickson writes:
>
On Jul 25, 2004, at 6:34 PM, Shawn Erickson wrote:
>
>
>
>
> On Jul 25, 2004, at 5:57 PM, Matt Jaffa wrote:
>
>
>
>> Hi,
>
>>
>
>> I have successfully tracked down how to repeat my KEXT causing kernel
>
>> panics, and I have successfully connected to it remotely to debug,
>
>> but once I am connected and attached to the remote machine, what must
>
>> I type/do to figure where in the code was the problem?
>
>
>
> Not sure someone can help you much via the medium of email, it is a
>
> big complex subject... I suggest reviewing what documentation you can
>
> find on GDB and any example of using it.
>
>
>
> Have you looked over the following that Apple provides...?
>
>
>
> <http://developer.apple.com/documentation/Darwin/Conceptual/
>
> KernelProgramming/build/chapter_18_section_5.html>
>
>
>
> <http://developer.apple.com/technotes/tn2002/tn2063.html>
>
>
Oops... I meant to point out the use of the "trace" command in GDB is
I think you meant the "backtrace" (or "bt") command that shows stack
back-trace. It's usually too late to use tracepoints when kernel
panicked.
>
likely the first step if you have it trapped during a panic in the
>
debugger. If you have symbols for your KEXTs loaded it should quickly
>
point you to the location of the issue. Additionally you can down load
>
the symbols for the kernel you are running [1] to be able to better
>
understand the Apple half of the equation.
>
>
Also the Apple folks have a set of GDB macros to help debug IOKit, etc.
>
however I cannot recall how to get them at the moment.
They are in kgmacros file in the top-level directory of XNU source. Load
this file with "source kgmacros" (or, better yet, put this into your
.gdbinit), and then "help kgm" provides an overview.
By the way, I have related question. When kernel is under debugger
control for enough time (for example, when I single-step through kernel
code, or just inspect kernel data), fans start rotating faster and
faster, emitting rather loud noise. It looks like CPU monitoring
hardware is confused somehow (maybe thinks that CPU is in busy loop with
interrupts off?), or just cannot work correctly without constant OS
feedback. So, questions are:
(a) is it possible to work around this, and
(b) is it dangerous (like, can it ultimately damage fans)?
>
>
-Shawn
>
Nikita.
_______________________________________________
darwin-kernel mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/darwin-kernel
Do not post admin requests to the list. They will be ignored.