#18915 closed bug (fixed)
PANIC: page fault, but interrupts were disabled
Reported by: | bbjimmy | Owned by: | nobody |
---|---|---|---|
Priority: | blocker | Milestone: | R1/beta5 |
Component: | System/Kernel | Version: | R1/Development |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | All |
Description (last modified by )
Attachments (1)
Change History (40)
by , 5 months ago
Attachment: | IMG_20240612_074820386_HDR.jpg added |
---|
comment:2 by , 5 months ago
comment:3 by , 5 months ago
comment:4 by , 5 months ago
Description: | modified (diff) |
---|---|
Summary: | PANICK: page cault but interrupts were disabled. → PANIC: page fault, but interrupts were disabled |
Version: | R1/beta4 → R1/Development |
comment:5 by , 5 months ago
From those it looks like the issue may have been introduced in hrev57761
follow-up: 8 comment:7 by , 5 months ago
A bit unrelated but I don't know another place that Korli can see. It is fine to get non-root element of binary heap? It will be not guaranteed to be next minimum/maximum value. Heapify operation will be required.
- inline Element* PeekRoot() const; + inline Element* PeekRoot(int32 index = 0) const;
comment:8 by , 5 months ago
Replying to X512:
A bit unrelated but I don't know another place that Korli can see. It is fine to get non-root element of binary heap? It will be not guaranteed to be next minimum/maximum value. Heapify operation will be required.
I'm not expert on this. As there is no unit tests for the MinMapHeap, it's difficult to evaluate. Non-root elements are only needed when the top element doesn't fit on the current CPU/Core/Package. Are you able to identify the heapify operation in this class?
follow-up: 12 comment:10 by , 5 months ago
follow-up: 13 comment:11 by , 5 months ago
Same here...I had an immediate page fault even before the the Rocket showed up for x86_64 running on QEMU with hrev57763.
comment:12 by , 5 months ago
follow-up: 14 comment:13 by , 5 months ago
Replying to CodeforEvolution:
Same here...I had an immediate page fault even before the the Rocket showed up for x86_64 running on QEMU with hrev57763.
Thanks for the feedback, I'm afraid hrev57765 isn't yet available. See #18917
follow-up: 16 comment:14 by , 5 months ago
follow-up: 17 comment:16 by , 5 months ago
follow-up: 18 comment:17 by , 5 months ago
comment:18 by , 5 months ago
Replying to korli:
Replying to kim1963:
In hrev57768 broken CPU "Energy saving mode"
Thanks for the feedback. What do you mean by broken?
You can reproduce the bug like this - turn on the energy conservation mode - Dooble browser - to go to YouTube.com repeatedly verified by assembly 57768 64 bits - CPU i5-8400
As a result, we get KDL panic and spontaneous reboot of the computer.
comment:26 by , 5 months ago
follow-up: 28 comment:27 by , 5 months ago
hrev57793 - broken
As a result, we get KDL panic and spontaneous reboot of the computer.
follow-ups: 29 30 31 comment:28 by , 5 months ago
comment:29 by , 5 months ago
comment:30 by , 5 months ago
follow-up: 35 comment:34 by , 5 months ago
Please comment only once for that, subscribers get an email for every new comment you post.
follow-up: 38 comment:35 by , 5 months ago
Replying to nephele:
Please comment only once for that, subscribers get an email for every new comment you post.
I had these too. It's a Trac problem, the page request stays in-flight. Reloading the page doesn't show the comment, whereas it should.
comment:38 by , 5 months ago
comment:39 by , 5 months ago
Just got this panic with hrev57804 (64 bits). "Power saving" mode was enabled at the time.
I was testing a build of https://github.com/fabiangreffrath/taradino/ (needs shareware data from: https://maniacsvault.net/ecwolf/files/shareware/1rott13.zip, and using -DTARADINO_SHAREWARE=ON
on the cmake line).
KDL mentioned _user_mutex_sem_release (nearest) + 0x1060
and Scheduler::ThreadData::ChooseCoreAndCPU(...)
.
KDL happened after trying to exit taradino
, having to kill it because it hangs on some midi code, and restarting it 2 times.
Without using "Power saving" mode, program runs/restarts fine (besides the midi issue). Trying again with Power saving mode enabled... couldn't reproduce the KDL, but system froze 2 times (had to force power down).
Image of the Kernel PANICK