Re: debugging kernel paniced system
Re: debugging kernel paniced system
- Subject: Re: debugging kernel paniced system
- From: Godfrey van der Linden <email@hidden>
- Date: Mon, 26 Jul 2004 10:52:17 -0700
G'day Nikita,
The KDP protocol is transported using the ethernet driver that is
polling. This causes the CPU to spin really, really fast, (I'm not
sure what the other CPU is doing during this). So you are using 100%
of the CPU to keep up with the network, this needs to be cooled.
Now when you start debugging you are deliberately setting the system up
to ONLY run your code in the driver being debugger. Unfortunately this
stops the fan controller driver from running. Thus the system
fails-safe by spinning up the fans until the driver start running
again. As you are using 100% CPU you probably do need to let the fans
go anyway.
You may be able to workaround the fans by breaking up your debugging
into sections. Instead of thinking at the GDB prompt, continue the
system then set another breakpoint after your have done your thinking.
Finally as a general rule the system doesn't appreciate being unable to
run for too long, (I can't define 'too' long as it depends).
Godfrey
On Jul 25, , at 0:30, Nikita Danilov wrote:
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)?
_______________________________________________
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.