Page 1 of 1
Interrupts
Posted: Sat Aug 31, 2002 4:04 pm
by 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
Re:Interrupts
Posted: Sat Aug 31, 2002 4:19 pm
by 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
Re:Interrupts
Posted: Sat Aug 31, 2002 4:25 pm
by Curufir
Many thanks, that clears things up quite a lot.
Re:Interrupts
Posted: Sat Aug 31, 2002 6:00 pm
by 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
Re:Interrupts
Posted: Sat Aug 31, 2002 6:47 pm
by 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)
Re:Interrupts
Posted: Sat Aug 31, 2002 7:43 pm
by 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.
Re:Interrupts
Posted: Sat Aug 31, 2002 9:47 pm
by Warmaster199
...and now I am silent ::)
Re:Interrupts
Posted: Sun Sep 01, 2002 1:02 pm
by Pype.Clicker
Warmaster199 wrote:
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.
Re:Interrupts
Posted: Sun Sep 01, 2002 6:26 pm
by Tim
however, i suggest you ALWAYS have DS=ES for movsb operations.
Also, C and C++ pretty much require you to have DS=SS.
Re:Interrupts
Posted: Sun Sep 01, 2002 10:06 pm
by Warmaster199
Gah! I said generally CS, DS = kernel code --- ES, FS = user code. I guess I have some more research to do eh? ;D ::)
Re:Interrupts
Posted: Mon Sep 02, 2002 1:37 am
by Pype.Clicker
Curufir wrote:
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 ?
Re:Interrupts
Posted: Mon Sep 02, 2002 2:57 am
by Tim
Warmaster199 wrote:
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.