Re: debugging kernel paniced system
Re: debugging kernel paniced system
- Subject: Re: debugging kernel paniced system
- From: Andrew Gallatin <email@hidden>
- Date: Mon, 26 Jul 2004 14:26:27 -0400 (EDT)
Nikita Danilov writes:
>
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
I work around the noise by taking a dump of kernel memory to
another machine. This works remarkably like "crashdumps" on
tradidtional UNIX machines (ie, you don't need to keep the machine in
the crashed state, you can reboot and debug the crash later). Its
loud for a while, but usually its finished dumping before I could have
finished with a gdb session.
You just need to have kdumpd running via inetd somewhere on your
network, and you need to have the appropriate boot args.
I use:
boot-args -v debug=0xdae _panicd_ip=172.31.193.10
This causes dumps to go to 172.31.193.10 (my FreeBSD server, running
kdumpd out of inetd). It also causes a dump to be taken when I
press the power button (rather than sleeping the computer).
The FreeBSD inetd.conf entry looks like the following (a new-fangled
MacOSX inetd.conf entry would look different).
kdumpd dgram udp wait root /usr/libexec/kdumpd kdumpd -l -u gallatin -s /home/gallatin/macdump
I also needed to add this line to /etc/services on the FreeBSD
machine:
kdumpd 1069/udp
I end up with cores (with names like core-xnu-517-172.31.193.9-1a8f2e15)
written to /home/gallatin/macdump. After that, you run gdb mach_kernel
core-xnu-517-172.31.193.9-1a8f2e15
Drew
_______________________________________________
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.