Try to find out the mistake...

[The_Pro]

hello all,
i've started writing a 32-bit os. i've started writing the interrupts. when i generate the "division by zero" exception, i get the error message as "13 (3rd) Exception with no resolution". could anyone try to solve the error and makes the exception to be caught. i've attached my secondary boot-loader. my mail-id is [email protected]. any help will be greatly appreciated.

thankx

[attachment deleted by admin]

[beyondsociety]

Where is the file?

The divide-error fault occurs during a DIV or an IDIV instruction when the divisor is zero.

Its hard to say what exactly is causing your code to tripple fault but if you look at ch.9 in the volume 3 intel manuals under General protection fault, It will tell you the mainy reasons why your code might tripple fault.

Hope this helps.

[Pype.Clicker]

dude, you attached nothing, and your challenge is not even challenging as your error is one of the most well-known and discussed around here ...

What about configuring your BOCHS to have an internal debugger and look out what's wrong by yourself? Looking at the sourcecode is not the good way to find tricky bugs efficiently. Get your error reproduced, track its location if possible (i.e. is it when you call the interrupt or when you return from it) and what is its cause (i.e. check IDTR values are what you expect, that your IDT content is correct and that your whole kernel get loaded by inspecting memory).

When all this will be done *and only then* do you have the information needed to look at your code and see what is wrong.

http://www.mega-tokyo.com/forum/index.p ... eadid=4453
http://www.mega-tokyo.com/forum/index.p ... eadid=4485 (oh !? that was you already :p )
http://www.mega-tokyo.com/forum/index.p ... eadid=4474
http://www.mega-tokyo.com/forum/index.p ... eadid=4471
http://www.mega-tokyo.com/forum/index.p ... eadid=3254

-- oh, sorry if i sound rude ... you're just N+1th the "Pype.repeat()" caller who unfortunately triggered the "Pype.RTFMException". Do not take it personnally.

[The_Pro]

sorry,

now, i've posted the file.

thankx

[Pype.Clicker]

<< BUG : 500 Hp >>
[bThe Pro[/b] : I know how to deal with it. Interrpts are disabled, i'll send a DIV
<< BUG defends : zeroed divisor >>
The Pro: aouch! that was a Div by Zero
Pype: hahaa... come over here bug! i'll defeat you
BUG: bwahahaa
<< BUG attacks The PRo: General Protection Fault >>
The pro: aargh! i have no handler ... i'll get a Double Fault
Pype: lemme take my ASM sword and patch your source code... Just the time to send a CTRL+Z spell on that Bug and i fix you
<< Pype uses Sleeping magic Spell CTRL+Z>>
Pype: Now let's you at you
The pro: Quick ... It hurts
Pype: true! you're almost moving to 3rd exception. Just because you have no Code selector in your IDT entries ...
<< Pype applies patch: dw 0x08 ; segment selector >>
<< The Pro recovered >>
Pype: that one was too easy.
Next time you try to send exception spells, make sure you protected yourself with a GPF handler first: it'll be easier for you to recover from BUG strikebacks.

[BI lazy]

];->

C'est magnifique, monsieur Pype le Grand .
*rofl*

exception spells ... oh really daaaaark magic they are.

[Solar]

I admit I haven't written a single exception handler myself, yet, and can't make much sense out of your handler, yet, but I will make a wild guess, based on what RTFM I have done so far...

ftp://download.intel.com/design/Pentium ... 547212.pdf

Chapter 5.6, p. 147:

For fault-class exceptions, the return instruction pointer that the processor saves when it generates the exception points to the faulting instruction.

Chapter 5.14, p. 162:

Interrupt 0 - Divide Error Exception (#DE)

Exception Class - Fault.

Did you take into account that, after returning from your handler, the faulting instruction will be executed again (i.e., did you resolve the problem in your handler)?