#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 |
Description
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 , 15 years ago
comment:2 by , 15 years ago
| Resolution: | → invalid |
|---|---|
| Status: | new → closed |
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 , 15 years ago
| Resolution: | invalid |
|---|---|
| Status: | closed → reopened |
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 , 15 years ago
| Resolution: | → invalid |
|---|---|
| Status: | reopened → closed |
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.
That's not really possible, as KDL runs with interrupts disabled.