Interrupts

[Curufir]

Got my GDT and IDT setup properly and switched to pmode, I can call an interupt (Verified that by printing to screen in a loop) but can't seem to IRET from it. Or at least as soon as I do IRET the processor triple faults.

Would this be because I haven't setup IDT entries to handle all the Intel reserved stuff? (Right now the IDT just has 1 entry). It seems from the manual that the IRET turns interrupts back on, and then something is trying to call another interrupt and failing miserably, faulting the CPU.

If that's the case then which one's do I need to handle? An earlier post mentioned 0-17 as needing to be handled, with the rest up to 31 getting set to the null descriptor. Is that correct?

Thanks,

Curufir

[Warmaster199]

Interrupts 7-15 are actually IRQ0-7 and Ints 70-78 are IRQ8-15(I believe, but that doesn't matter if you remap the PIC ). Yes, you do need the first set of interrupts in PMode, so you must remap the 8259 chips(PIC A, PIC B). Most (if not all!) modern O.S.es remap the PICs from interrupts 0x20 - 0x2F. These interrupts, which can be given a NULL descriptor, should later be given a function to call. IRQ0(Int 0x20) is the timer's interrupt. This defaults to fire every 18.2222222Hz. Use this for a multitasking OS'es scheduler..., IRQ1 is for the keyboard... etc. Many people on this forum have posted code from their OS'es. Just take a look at some of it and you will get a good idea of what's going on

[Curufir]

Many thanks, that clears things up quite a lot.

[Curufir]

Cleared it up, but not quite enough

Has anyone got any idea why this as an ISR works:
PUSHA
PUSH DS
MOV AX, Data_Sel
MOV DS, AX
MOV ESI, 0xB8000
MOV WORD[DS:ESI],'O '
POP DS
POPA
IRET

When if you use exactly the same code but using GS instead of DS you get an exception when you hit the IRET (Running through debug shows the stack doing...err...odd things). A Bochs bug? Or actual behaviour? It seems pretty wierd.

Curufir

[Warmaster199]

GS is not refering to the kernel's code/data. It is NOT a bug. The processor always uses CS/DS in supervisor(kernel) mode. ES, EF, and GS are for user processes. If you use GS, that's a user segment, so the processor is looking elsewhere. Changing the segment to the data_sel should not really matter.

Anyways, try to keep it general... CS, DS = Kernel. ES, FS, GS = User.(Those are the standard assignments)

[Curufir]

Actually I figured it out. Taking another look through the code I noticed that at no point after switching to PMode had I loaded GS with a valid descriptor (ES and FS worked so I didn't think your take on the problem is right Warmaster). Because I never changed it GS had a value of 0xffff and for some reason pushing that played havoc with the stack pointer if it got pushed.

I still find that hard to accept seeing as the GDT can theoretically have 8192*8 byte descriptors, but it's definitely the thing causing it. As soon as I loaded a valid descriptor in I could push it without any ill effects whatsoever.

[Warmaster199]

...and now I am silent ::)

[Pype.Clicker]

GS is not refering to the kernel's code/data. It is NOT a bug. The processor always uses CS/DS in supervisor(kernel) mode. ES, EF, and GS are for user processes. If you use GS, that's a user segment, so the processor is looking elsewhere. Changing the segment to the data_sel should not really matter.

Anyways, try to keep it general... CS, DS = Kernel. ES, FS, GS = User.(Those are the standard assignments)

completely wrong info! any segment register can hold any kind of data segment, regardless of its DPL level. however, i suggest you ALWAYS have DS=ES for movsb operations. The assignment for FS and GS is design-specific (but one of those is usually kept by convention equal to the user-mode's DS segment for datas copying between user and kernel space when invoking a system call)

Code: Select all

PUSHA
PUSH GS
MOV AX, Data_Sel
MOV GS, AX
MOV ESI, 0xB8000
MOV WORD[GS:ESI],'O '
POP GS
POPA
IRET

has absolutely no reason to work bad if the code with DS works.

[Tim]

however, i suggest you ALWAYS have DS=ES for movsb operations.

Also, C and C++ pretty much require you to have DS=SS.

[Warmaster199]

Gah! I said generally CS, DS = kernel code --- ES, FS = user code. I guess I have some more research to do eh? ;D ::)

[Pype.Clicker]

Cleared it up, but not quite enough

Has anyone got any idea why this as an ISR works:

When if you use exactly the same code but using GS instead of DS you get an exception when you hit the IRET (Running through debug shows the stack doing...err...odd things). A Bochs bug? Or actual behaviour? It seems pretty wierd.

Curufir

maybe you should try IRETD instead of IRET. some versions of nasm had a bug about it if i remember well ...


by the by, are you sure your data descriptor is valid (did you used it previously ?) and can support 32 bits offsets ? (BIG flag set ?)

how did you call your interrupt ?
are you in CLI or STI mode ?

[Tim]

Gah! I said generally CS, DS = kernel code --- ES, FS = user code. I guess I have some more research to do eh? ;D ::)

Yes...

CS = code
SS = stack
DS, ES, FS, GS = data

Whether they're kernel or user depends on what selector is loaded into them at the time.