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 | 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.