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 | darwin-kernel@lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.