int_trap_gate(): selector null

[Monkeycat]

Hello,

I try to run my OS in bochs but it crashes when I do:

Code: Select all

asm("sti");

When I check bochsout.txt I see:

00001915515p[CPU ] >>PANIC<< int_trap_gate(): selector null

On VMware I get:

"Virtual machine kernel stack fault (hardware reset)"

I have a simple idt for now:

Code: Select all

loadIDT:

        lidt[idt_ptr]
        ret

[section .data]

idt:
%rep 256
        dw 0
        dw 0x10   ;data selec
        db 0
        db 0
        db 8Eh
        dw 0
%endrep
idt_end:

idt_ptr:
        dw idt_end - idt - 1
        dd idt

and my gdt:

Code: Select all

[section .text]

loadGDT:
  lgdt [gdt_ptr]

  ; set segment registers
  mov ax, dataSel               ;0x10
  mov ds,ax
  mov es,ax
  mov ss,ax
  mov fs,ax
  mov gs,ax

  ret                                   ; return back to the kernel


[section .data]

gdt:
; NULL descriptor       ; 00000h
        dw 0            ; limit 15:0
        dw 0            ; base 15:0
        db 0            ; base 23:16
        db 0            ; type
        db 0            ; limit 19:16, flags
        db 0            ; base 31:24

; unused descriptor     ; 0008h
        dw 0
        dw 0
        db 0
        db 0
        db 0
        db 0

dataSel equ     $-gdt      ;0010h, points to base address 0
        dw 0FFFFh
        dw 0
        db 0
        db 92h          ; present, ring 0, data, expand-up, writable
        db 0CFh         ; page-granular (4 gig limit), 32-bit
        db 0

codeSel equ     $-gdt      ; 0018h
        dw 0FFFFh
        dw 0
        db 0
        db 9Ah          ; present,ring 0,code,non-conforming,readable
        db 0CFh         ; page-granular (4 gig limit), 32-bit
        db 0

videoSel equ           $-gdt
        dw 0FFFFh
        dw 0x8000
        db 0x000b
        db 92h
        db 0CFh
        db 0
gdt_end:

gdt_ptr:
        dw gdt_end - gdt - 1
        dd gdt          ; linear, physical address of GDT

Can anyone please shed some light on this... Do I even need the 'unused descriptor' ?

Thanks for all the help!

[nullify]

Do I even need the 'unused descriptor' ?

No. At a bare minimum, all that is necessary is null, code, and data.

As for your crash after enabling interrupts, perhaps some hardware IRQ's are unexpectedly firing? Try masking all IRQ's before you asm("sti"). I'm not certain if this is the problem, but its worth a try if nothing else. Your GDT and IDT appear to be OK (although I haven't inspected them thoroughly).

[Pype.Clicker]

why do all your interrupt have a pointer to the data selector ? it should be a *code* selector, you know ?

[Thunder]

I have the same problem on VMware, so now I can explain, why on my computer OS works fine, but there are some PCs, that have the same problem :-\

[Pype.Clicker]

btw, unless you have some magic function that fills your IDT with some correct handler addresses, it is unwise to let all those 'handler offset' to 0 (unless you have something special at 0). Better redirect them to a default handler of yours (that will for instance write down 'PANIC' on screen and freeze the CPU).

If by anychance 0 is your 'start' address, it means that your OS will restart 18.2 times per second as soon as you enable interrupts...

[Monkeycat]

Hello,

I was trying to isloate the problem so I took out the idt and isr code. I try to do 'sti' after I loaded my gdt and it still crashed. Is this normal when you don't have a idt ?


thanks

[Pype.Clicker]

absolutely: when you try to use an IDT entry which is above IDT.limit (and no idt means limit==0), you'll get a GPF. As the CPU cannot access the GPF handler (still for the same reason), it triggers a double fault.

And the double fault exception cannot be found, which is a triple fault condition which resets the CPU.

It would be wiser to install an IDT and *not* enabling hardware interrupt requests immediately. Instead, check you can call a interrupt with INT n instruction first, and then put some exception handlers (on interrupts slots 0..1F) that will tell you what exception occured (you're invited to try them too with x=x/0, etc).

Only then can you enable hardware interrupts without fearing a reset (oh, btw, make sure you remapped the PIC so that IRQ0 is somewhere above 0x20 and not on 0x08 or you'll receive weird error reports )

[Monkeycat]

Hello,

I combined my isr and idt into one file:

Code: Select all

[BITS 32]

GLOBAL loadIDT
extern intHandler

[section .text]

loadIDT:
   lidt[idt_ptr]
   ret

_int0:
   cli
   pusha
   push es
   push ds
   push fs
   push gs

   mov eax, 0
   mov gs, eax
   mov fs, eax
   mov eax, 0x10    ; offset from idt 0x10, is this right??
   mov es, eax
   mov ds, eax

   call intHandler

   pop gs
   pop fs
   pop ds
   pop es
   popa
   sti
   iretd

[section .data]

idt:
; interrupt 0 
   dw 0         ; bits 0-15 of isr's address 
   dw 0x18      ; code selector from gdt [writable]
   db 0
   db 0
   dw 0x8E      ; 32-bit, ring 0, interrupt gate
   dw 0x10      ; offset
idt_end:

idt_ptr:
   dw idt_end - idt - 1
   dd idt

Yet when I do sti Bochs still crashes with this in error log:

00000882452i[BIOS ] *** int 15h function AX=00C0, BX=0000 not yet supported!
00000886931i[BIOS ] *** int 15h function AX=5300, BX=0000 not yet supported!
00000891363i[BIOS ] *** int 15h function AX=5304, BX=0000 not yet supported!
00001880675p[CPU ] >>PANIC<< exception(): 3rd (13) exception with no resolution

I checked to see what int 15 function C0 was and it seems to be a "Return system configuration parameters (PS/2 only). Am i right to think this is something that Bochs checks to its initlizations?

I am still not sure if I have the offset correct on my ISR. Can anyone tell me whats going on?

thanks for all the help!

[nullify]

Code: Select all

idt:
; interrupt 0 
   dw 0         ; bits 0-15 of isr's address 
   dw 0x18      ; code selector from gdt [writable]
   db 0
   db 0
   dw 0x8E      ; 32-bit, ring 0, interrupt gate
   dw 0x10      ; offset
idt_end:

What I think you meant to do is:

Code: Select all

idt:
; interrupt 0 
   dw (bits 0-15 of ISR) 
   dw 0x18      ; code selector from gdt [writable]
   db 0
   db 0x8E      ; 32-bit, ring 0, interrupt gate
   dw (bits 16-31 of ISR) 
idt_end:

Yet when I do sti Bochs still crashes with this in error log:

Again, don't bother doing STI until you have IRQ's masked. You can still test your interrupt handlers by executing an INT instruction, as Pype.Clicker pointed out earlier.

I am still not sure if I have the offset correct on my ISR. Can anyone tell me whats going on?

Nope, you don't have the offset correct. The offset is the address of the ISR (address of _int0 in this case). You must get the lower word of the address into the first field of the IDT entry, and the upper word of the address into the last field of the IDT entry.

[Therx]

idt:
; interrupt 0
dw 0 ; bits 0-15 of isr's address
dw 0x18 ; code selector from gdt [writable]
db 0
db 0
dw 0x8E ; 32-bit, ring 0, interrupt gate
dw 0x10 ; offset
idt_end:

This gives us a 10 byte IDT entry, interesting the format (as I've just posted in another thread) is:-

Code: Select all

dw - Low 16bits of handler address
dw - Code Segment Selector
db - Null Byte
db - Flags
dw - High 16bits of hander address

TOTAL 8 bytes

Pete