Opened 14 years ago

Closed 14 years ago

Last modified 14 years ago

#4693 closed bug (invalid)

when in kernel debug land, the CPUs spike up to 100% use

Reported by: StephaneCharette Owned by: axeld
Priority: normal Milestone: R1
Component: System/Kernel Version: R1/alpha1
Keywords: Cc:
Blocked By: Blocking:
Platform: All


I have Haiku running on a 4-CPU system within VirtualBox. When a problem happens that causes the Kernel Debug Land to display within Haiku, all 4 of my physical CPUs on my host spike up to 100% usage, and remain there until I exit or reboot from KDL.

It would be nice if there were some yields or sleeps or ...? to ensure that host systems aren't pegged at 100% usage when Haiku has a failure.

Change History (5)

comment:1 by anevilyak, 14 years ago

That's not really possible, as KDL runs with interrupts disabled.

comment:2 by anevilyak, 14 years ago

Resolution: invalid
Status: newclosed

If you don't have time/inclination to actually track down the backtrace, you can use the kernel settings file (config/settings/kernel/drivers/kernel) to disable KDL and have it reboot on panic instead, but the issue described is not fixable without essentially rendering the kernel debugger useless.

comment:3 by StephaneCharette, 14 years ago

Resolution: invalid
Status: closedreopened

What I don't understand is why all 4 of my CPUs would spike to 100% usage. So if KDL spins somewhere waiting for user input before running a command, that would mean 1 of my CPUs would spike to 100% while the rest remain idle. But all CPUs spiking to 100% usage means we have at least 4 threads doing nothing but busy loops while it sits at the KDL prompt waiting for user input.

I'm new to Haiku, so I have zero understanding on how the Haiku kernel works, and I apologize for this. But it seems to me like this bug ticket was closed somewhat quickly, with an explanation that -- as a software developer but not a Haiku kernel developer -- I unfortunately don't understand.

comment:4 by anevilyak, 14 years ago

Resolution: invalid
Status: reopenedclosed

The problem as I said is interrupts are disabled. This applies to all CPUs, not just the current one, as they must all enter KDL when a panic happens. However, since they're disabled, you cannot use any idling techniques, since those invariably involve sleeping until an interrupt. Trying to do that with ints disabled would permanently kill the session since you'd never be able to wake the CPU up again without completely resetting the system. As such this is simply an unavoidable consequence.

comment:5 by StephaneCharette, 14 years ago

Thank you, anevilyak, for the explanations.

Note: See TracTickets for help on using tickets.