OSDev.org

The Place to Start for Operating System Developers
It is currently Thu Mar 28, 2024 6:32 am

All times are UTC - 6 hours




Post new topic Reply to topic  [ 19 posts ]  Go to page Previous  1, 2
Author Message
 Post subject: Re: CPU Properties
PostPosted: Wed May 26, 2021 7:36 pm 
Offline
Member
Member

Joined: Thu Jan 07, 2021 2:01 pm
Posts: 67
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.


Top
 Profile  
 
 Post subject: Re: CPU Properties
PostPosted: Wed May 26, 2021 8:33 pm 
Offline
Member
Member

Joined: Mon Mar 25, 2013 7:01 pm
Posts: 5099
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.


Top
 Profile  
 
 Post subject: Re: CPU Properties
PostPosted: Thu May 27, 2021 12:16 am 
Offline
Member
Member
User avatar

Joined: Thu Oct 13, 2016 4:55 pm
Posts: 1584
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


Top
 Profile  
 
 Post subject: Re: CPU Properties
PostPosted: Thu May 27, 2021 2:13 am 
Offline
Member
Member

Joined: Wed Oct 01, 2008 1:55 pm
Posts: 3191
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 19 posts ]  Go to page Previous  1, 2

All times are UTC - 6 hours


Who is online

Users browsing this forum: Bing [Bot], SemrushBot [Bot] and 69 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group