OSDev.org

In theory, yes. But the way my fault handling works (and I admit I should change it) is when an exception occurs, it stops execution and halts the CPU. This is mainly done so I can step through issues one by one. It also forces me to fix one problem before I move onto the next. As you may have noticed, my brain likes to jump around a lot, lol.

TheGameMaker90 wrote:But the way my fault handling works (and I admit I should change it) is when an exception occurs, it stops execution and halts the CPU.

Halting the CPU is fine. The problem is that when you halt the CPU, you need to display enough information to figure out why the CPU halted. Right now, you don't display enough information, so you wasted your time on that XOR instruction when the problem is elsewhere.

Octocontrabass wrote:Halting the CPU is fine. The problem is that when you halt the CPU, you need to display enough information to figure out why the CPU halted.

That's absolutely right. Take a look at the kernel panic wiki page, it has some useful hints what to do when an unhandled exception happens.
You could integrate minidbg for example, it's dependency-free.

Cheers,
bzt

bzt wrote:

Octocontrabass wrote:Halting the CPU is fine. The problem is that when you halt the CPU, you need to display enough information to figure out why the CPU halted.

That's absolutely right. Take a look at the kernel panic wiki page, it has some useful hints what to do when an unhandled exception happens.
You could integrate minidbg for example, it's dependency-free.

Cheers,
bzt

I feel that these panic definitions are a bit too broad. Apparently, it seems like either you ignore an error or kill the system. This is not very useful for systems debugging.

I have two modes of "panic".

The most common is when a driver encounters a fault, or and int 3 instruction is placed in the code on purpose to catch abnormal conditions. This is not a fatal error and so don't need to stop the rest of the system. If this happens in a production release, the watchdog will catch the error, create a fault report and potentially write it to disc. After this, an automatic reboot is done. If it happens in a debug release, nothing happens and the faulting thread can be debugged in the kernel debugger which is always active.

The real panic function is only activated if a fault happens while the scheduler is locked. This happens if IRQs fault, kernel stack is exhausted or if the scheduler faults. It can also be triggered intentionally with an int 0x80 in the code. The panic will stop all processor cores and then one of them goes into a monitor which is completely isolated from the operating system. The monitor has an instruction emulator that can step code so it is possible to see what happens when a particular piece of code is executed. Faults will be entered, including page fault, something that is invisible when using a normal debugger. Part of the problem is that different screen modes must be handled, including font rendering, but also that various keyboards must be supported. In the beginning I only supported PS/2, but now I also have some support for USB keyboards. The panic function is also dependent on "build mode". In a production release, the core states are saved at a fixed memory position, and then a reboot happens. If BIOS doesn't touch this memory, it can be read and saved after the OS comes up again. In a debug release, the monitor is started.