OSDev.org

Hi,

OSMAN wrote:mov ax, isr0-$$ & 0xFFFF
mov [start_of_idt],ax
mov ax, (isr0-$$ >> 16) & 0xFFFF
mov [start_of_idt+6],ax

I meant it to fill the first slot of the empty IDT with isr #0 (, which exists of course), but it crashes my kernel! Why?
(I call it before "sti" and "call main")

Please tell me the correct version of this.

Is this the problem you're stuck on? I'd be surprised if anyone can find anything wrong with the code posted (seems fine to me).

What makes you think the code above crashes your kernel, and why does it crash your kernel? For example, what does your Bochs log say?


Cheers,

Brendan

OSMAN wrote: I will do it in C later, but could you now PLEASE give me what I've asked for in 6 mails already!?!!!!!!

You do realise that anybody giving you answers is not being paid to do so, is not gaining anything else and only does it because you asked nicely?

So, could you next time at least ask nicely?

Okay. I try to emulate asking nicely

That code seems to work for Brendan, okay ; what does it do for Brendan ? For me it should fill the IDT entry # 0, but it does not do so ! It might, but even I've remapped PIC and try to divide by zero, ISR0 gets not executed!
So what's the problem? ( 8 mails ) ( More info about my situation in mails above )

( I'm just little anti-patient with OS dev.things )

PS. It won't crash my kernel ; I made a mistake ; that was another thing which crashed it

It would be nice for me to even have the interrupts working :-\

I don't know if you can call forum posts for mails, it sure sounds funny to me. What happens when you run it, does your computer just hang or does it reset?
Debug your code in BOCHS.

Bochs doesn't reset or anything. It just does nothing ; prints "hello" to the screen and stays in an while ( true ) - loop. My exception 0 isn't coming whatever I try. I guess the problem is in my IDT, would you have a clue?

( I haven't called "sti" , because before main it crashes the kernel and in main asm ( "sti" ) does nothing. )
( If it depends on STI, would you know any way to call it the right way? )

( 9 letters )

Hi,

OSMAN wrote:Bochs doesn't reset or anything. It just does nothing ; prints "hello" to the screen and stays in an while ( true ) - loop. My exception 0 isn't coming whatever I try. I guess the problem is in my IDT, would you have a clue?

( I haven't called "sti" , because before main it crashes the kernel and in main asm ( "sti" ) does nothing. )

The CLI and STI instructions only control maskable IRQs, not exceptions, so STI isn't why your not getting the exception.

Are you doing something like:
Or perhaps:
If you are, then the first thing I'd do is make sure the compiler hasn't optimized it. If the variable "a" isn't used later on, then most compilers won't generate the code for the division. In this case (IIRC) the "volatile" keyword would fix it, for example "volatile int a;" instead of just "int a;".

If the division is definately in your binary, then it's either not being run at all (e.g. CPU never reaches it) or it's being run and not doing whatever you expect.

In either case, just before the division I'd put something like:
Then you'd be able to run the OS using Bochs debugger. After running it for a while, stop it (with control+C) and then type in 's' a few times to see if you're in the little loop above or not. This will tell you if the division would have been executed or not.

If the division would've been run then Bochs will be stuck in the little loop. In this case, type in "set$ecx=1" to change ECX and break out of the loop. Then type in 's' until the division instruction is about to be executed, check the CPU's registers (with "infor"), and then type in 's' once more to see where the CPU goes.


Cheers,

Brendan

Thanks for that volatile thing Brendan, it seemed to work. Bochs did notice my division by zero but it jumped somewhere that crashed the kernel and Bochs died!

Now we are reaching the problem and a kind of knowing that the problem is in: Now is really the time for you to describe me where it moves the bits in fact. So, what is the probelm why isr0 isn't found?

Or has my isr0 something towards wood? PS. I didn't know that Bochs can even interpret assembly run-time, cool.

Hey, does this, which I found from bochs.log, have anything to do with the problem? It happens just when I reach the "a=x/0;"

In your case it's a good thing.
Try to hang the computer instead of doing the EOI.

Tack f?r hj?lpen Bubach, men det var inte mitt problem.
My ISR didn't even get called; addresses ?r towards a wood!

Now I am totally confused!

No matter what way I try to get my IDT working (C, asm, C+asm), IT WON'T WORK! That's not inordinate for me! That's just a curse. I've tried all the ways you've told me and some ways more from some existing kernels.
By the way, thanks for all your help. But the subject will continue unti it gets working!

I've spent one evening per a way: first I mix the idea into my kernel, then I write the code error-free. But yeah, when I run the kernel, and an exception comes, kernel crashes and always the same Bochs-log line will remain (, that one is in the letter above).

Now, I am completely sure that my problem has nothing to do with IDT solutions, but my GDT or something else! (There's nothing else)

(I don't know much about GDT yet when I've focused in IDT the few past weeks. One thing per a time.)
Can the GDT cause this disgusting thing? And is there any free GDT working with IDT out there? (I'll focus on writing my own later)

PS. What do you mean by: "In your case it's a good thing.", when I get the bochs line? I want the exception to jump to its handler!

Hi,

OSMAN wrote:Now, I am completely sure that my problem has nothing to do with IDT solutions, but my GDT or something else! (There's nothing else)

The list of possible problems would include the linker script, the assembly stub, the GDT, any code that could accidentally overwrite something, etc...

OSMAN wrote:PS. What do you mean by: "In your case it's a good thing.", when I get the bochs line? I want the exception to jump to its handler!

I think what he means is that your divide error exception handler must not send an EOI to the PIC chips (it's not an IRQ), and must not return. The problem is that if you return from the exception handler, then you'll get the same divide error again, which would cause an infinite loop.

For now, the exception handler should display something once and stop ("jmp $"). Later on you'll have some sort of critical error handler that will do something (display the error, do a core dump, add details to a log file, etc) and then terminate the faulty application.


Cheers,

Brendan

?r du svensk? (are you swedish?)
Add me on msn or mail me (maybe i can help you) at bubach85 at hotmail..

Jag ?r inte svensk. But from the eastern neighbourhood.
I'd be pleased if you helped me personally! (But I can understand english a lot better than swedish.)

By the way, I got Interrupts working. Now I'd like to know how to enable and disable the interrupts I want (not like cli and sti). But after posting this I'll surely find it out.

(I'll add my e-mail address to my profile.)

Aha.
So what was it that made it work?
You mean that you want to enable and disable IRQ's?

To disable all IRQ's: To enable all IRQ's:

I don't know how I got Int.s working for sure. I rewrote my asm boiler-plate completely different way and modified the C code. Too much to explain.

But yeah, it feels great now when I can write the interrupt service routines!
This may be going out of topic...

Do you have any suggestions or advice for my ISRs?
(Now is the time again to open the Tanenbaum's Design and Implementation; it honestly had nothing about IDT and GDT, respectively.)