OSDev.org

Posted: **Wed Aug 14, 2024 10:44 pm**

So I'm messing around with IA-32, I enabled the GDT and IDT, everything is working nicely. However, when I enable the IDT -- I get a double fault as the first exception!

Code: Select all

Servicing hardware INT=0x08
Servicing hardware INT=0x08
     0: v=08 e=0000 i=0 cpl=0 IP=0008:002002a9 pc=002002a9 SP=0010:00209868 env->regs[R_EAX]=00201200
EAX=00201200 EBX=00010000 ECX=fd01530c EDX=00000010
ESI=00000000 EDI=00000000 EBP=00000000 ESP=00209868
EIP=002002a9 EFL=00200202 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
CS =0008 00000000 ffffffff 00cf9a00 DPL=0 CS32 [-R-]
SS =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
DS =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
FS =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
GS =0010 00000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT
TR =0000 00000000 0000ffff 00008b00 DPL=0 TSS32-busy
GDT=     00200030 00000017
IDT=     00205020 000007ff
CR0=00000013 CR2=00000000 CR3=00000000 CR4=00000600
DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000 
DR6=ffff0ff0 DR7=00000400
CCS=00000000 CCD=00209868 CCO=EFLAGS
EFER=0000000000000000

I notice two things:
1. It seems like the hardware interrupts themselves are causing this to happen
2. The IDT looks like it's in the wrong place -- but that's only an assumption.

The modifications I've done to the code that differ from the stuff on Github is just a "cli" at the start of _start in stub.s. The source code is here: https://github.com/mxtlrr/theta

Code: Select all

_start:
   cli
   ...

What's going on here?

Posted: **Thu Aug 15, 2024 1:35 am**

You need to remap the PICs. See https://wiki.osdev.org/8259_PIC . Without remapping IRQ0-IRQ7 the default is mapping them to exceptions 0x08 thru 0x0f. As I recall your code and stubs are set assuming the PICS are mapped from 0x20-0x27 (master PIC) and 0x28 to 0x2f (slave PIC).

Edit: I looked at your new repository. I see it is not really the old code at all. It is 32-bit and not 64-bit; the ISR routines don't save restore/registers etc; the error code isn't removed off exceptions with error codes etc. There is just a call to exception_handler followed by an iret. I cam confirm that the issue is that you enabled interrupts; got a timer interrupt; since the PICS haven't been remapped IRQ0 comes in on 0x08 which appears to your kernel to be a double exception fault (which it isn't). Once you properly remap the PICS you will need interrupt handlers for the external interrupts. Your code only has exception handlers (ISRs) for exceptions 0x00 to 0x1f so you will likely get general protection faults because of that.

OSDev.org

[SOLVED] Odd Behaviour when interrupts are turned on.

[SOLVED] Odd Behaviour when interrupts are turned on.

Re: Odd Behaviour when interrupts are turned on.