fault, etc

Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
Post Reply
digo_rp
Member
Member
Posts: 233
Joined: Sun Jun 05, 2005 11:00 pm

fault, etc

Post by digo_rp »

Guys, I have a question, could anyone helps me ?

for example, I have 2 tasks running at ring 3 so, that 2 tasks crash in the same fault, and the same time...

now is the question. my isr 13 e.g displays the error at screen and wait for a key, " enter " now, how could I hand that screen

for that 2 tasks at the same time ?

anyone knows how to take care of it ?

this example is in text mode.

in gui mode just wait for mouse click. the biggest problem is that I need interrupts enabled when that fault happens.
User avatar
Andr3w
Member
Member
Posts: 76
Joined: Tue Jun 09, 2009 4:09 am
Location: Somewhere

Re: fault, etc

Post by Andr3w »

digo_rp wrote: for that 2 tasks at the same time ?
2 tasks can't run at the same time - so they can't fail at the same time.
User avatar
mutex
Member
Member
Posts: 131
Joined: Sat Jul 07, 2007 7:49 pm

Re: fault, etc

Post by mutex »

Lets assume you have SMP working. I have, and i have seem similar issue when i created two threads out of same code once and that code generated a fault.

What i did was; create a mutex and lock it when you enter your "BlueScreen" or whatever function.. Then if your mutex function is coded properly with ATOMIC instructions then this should make sure only one of them make it further..

Thats atleast how i did it.. Btw; you could issue a NMI IPI to all other AP's and tell them to go "hang" around forever while the current AP running shows the bluescreen. Then you are sure nothing else is running in background.

-
Thomas
skyking
Member
Member
Posts: 174
Joined: Sun Jan 06, 2008 8:41 am

Re: fault, etc

Post by skyking »

Since it is ring 3 processes I guess that the kernel is still operational so there's really no reason why this at all should be a problem. There's really no reason to need the interrupts to be disabled just because some of the processes has faulted.

If the processes are interactive you should have some kind of method for switching keyboard focus, and preferably their separate output should be identifiable (writing to different areas of the screen/switchable consoles). In that case the fault handler could be run in parallel.
Post Reply