OSDev.org

He,

I've been having an anoying problem. When I boot my OS. load the kernel and jump to protected mode everything seems to be fine. (No reboot and everything is acting like it is supposed to be) But when I start initializing my interrupt handlers (map the pic, mask the IRQ's, install handlers, load idt, enable ints) I get an double fault (int It doesn't happen directly after sti, but a fixed number of instructions later. But the strange thing is that the number if instr later is also dependend of the instructions before the sti. When I put more instructions before sti the double fault comes sooner.

I've been debugging with bfe2 and bochs, but I can't find the problem. Has anyone got an idee?

Thanks, Lont

Have you enabled A20, and were is your os loaded to ?.
\\\\|////
(@@)
ASHLEY4.

Yes I've enabled my A20 and my OS is loaded at 0x100000 (1 meg). I first load my OS from disk, go to pmode and move the code to 1 meg and then jump to the kernel.

Lont

It sounds to me, that maybe your A20 code may not work on that pc,as some A20 code snips do not work on some pc's.
Try puting a number in memory above 1 meg and read it back,if you get the same number back, try 5k above that and so on.
\\\\|////
(@@)
ASHLEY4.

IMHO it's simply the IDT... I mean that perhaps you have some wrong entries in IDT. When you enable interrupts (BTW have you reprogrammed the PIC correctly?) after a certain amount of instructions a hardware interrupt (most likely a timer interrupt) occurs and if the IDT entry is wrong, you get an error... This explains dependance on the number of instructions before STI (the more instructions there are, the sooner the timer is going to pop). But maybe it's really A20...

Best regards,
EyeScream

Double fault is caused when an exception occurs while the CPU is trying to handle the previous exception. In some cases, both the exceptions can be handled serially. But, in most cases, the CPU generates a double fault. There are two main causes for DF, hardware and kernel stack overflows. Check your kernel stack and check whether you have initialized your stack pointer.

HTH

I reprogrammed the PIC correctly, I first wrote some code myself but to be sure it was correct I looked at other oses. I also thought it was the timer int, but I masked the timer int.

I don't think it is a faulty IDT entry, because I made all the entries identical (to be sure that this wasn't the problem) and other entrys work good (like the double fault one)

I was thinking, isn't it possible that a hardware int occured while the interrupts weren't enabled. Or does the computer reboot in such case?

Maybe it is the A20 line. I will have a look. Maybe that is why the double fault seems to occur after a fixed number of commands (end up at the same mem location).

Or could there be another problem? For example doesn't the IDT need to be on a 4-byte boundry or something?

I will first check out the A20 line, copy some code from somewhere.

Thanks,
Lont

This one works fine on all my pc.
;******************************************************************
enable_A20:
        pusha
        cli                                    ; Disable all irqs
        cld
        mov   al,255                           ; Mask all irqs
        out   0xa1,al
        out   0x21,al
l.5:    in    al,0x64                          ; Enable A20
        test  al,2                             ; Test the buffer full flag
        jnz   l.5                              ; Loop until buffer is empty
        mov   al,0xD1                          ; Keyboard: write to output port
        out   0x64,al                          ; Output command to keyboard
l.6:    in    al,0x64
        test  al,2
        jnz   l.6                              ; Wait 'till buffer is empty again
        mov   al,0xDF                          ; keyboard: set A20
        out   0x60,al                          ; Send it to the keyboard controller
        mov   cx,14h
l.7:                                           ; this is approx. a 25uS delay to wait
        out   0edh,ax                          ; for the kb controler to execute our
        loop  l.7                              ; command.
        sti
        popa
        ret
;**********************************************************************
\\\\|////
(@@)
ASHLEY4.

Heee, that code works!!! Thank you so much, I had tried 3 other peaces of code which all didn't work... Also found a site: http://www.tue.nl/sportcentrum/intcom.html It seems the A20 line has many strange problems.

Thanks again,
Lont