GPF caused by interrupt handler

[neon]

Hey everyone,

I previosuly posted here reguarding color problems and GPF.
The color was easily fixed, the GPF however, is not.

Please note that:

-My code works fine in Bochs emulator

-My code works fine on laptops

The problem is that a GPF happens on PCs, and PCs only.
From both machines, the GPF interrupt gave me the same
EIP, but different error codes:

Code: Select all

; pc 1:
eip: 0x265e
eflags: 0x1006
error code: 0x18

; pc 2:
eip: 0x265e
eflags: 0x1006
error code: 0xf000

I have done research on what the problem might be (I have looked at the
Intel docs)

Im kind of stuck n what the problem might be though.
Here is where the GPF is getting triggered:

Code: Select all

extern _Sys_IRQ_Handler

IRQ_Stub:

	; save state information
	
	pusha
	push		ds
	push		es
	push		fs
	push		gs
	
	; set stack
	
	mov		ax, 010h
	mov		ds, ax
	mov		es, ax
	mov		fs, ax
	mov		gs, ax
	
	; save stack address
	
	mov		eax, esp
	push		eax
	
	; execute IRQ handler

	mov		eax, _Sys_IRQ_Handler
	call		eax
	
	; restore registers
	
	pop		eax

; 0x0008:0265e --------------------------

	pop		gs  ; << for GPFs, EIP points to triggering instruction
	pop		fs
	pop		es
	pop		ds
	popa
	
	; IRQs push 2 values on stack, so restore stack
	
	add		esp, 8

	iret

The pop gs is the failing instruction. I know nothing is wrong
with the above code, and am confused on how a pop instruction
could generate the fault.

I suspect it might be my GDT or IDT. But, Why would it work on laptops
but not PCs...?

I am posting here hoping someone more experienced with OS dev
and GPFs can give me some suggestions.

Thanks!

[neon]

I followed the advice from This thread, except all of my interrupts are working fine...

..Except Int 32h.

[Brendan]

HI,

I'd assume that something in the "_Sys_IRQ_Handler" function is trashing the stack.

I'd be tempted to look for race conditions, where if an IRQ fires before something is ready it causes the problem (and where on some computers the timing is unlucky, and on others the timing is lucky).

For an example, imagine if the "_Sys_IRQ_Handler" function calls "IRQ0handler" and "IRQ0handler" does a task switch (including switching to a different stack), but when a new task is created it's possible for an IRQ0 to occur before you've initialised the new task's stack properly. In this case you may or may not crash, depending on the exact timing of IRQ0.

The other suggestion is to make sure you're not relying on uninitialised data somewhere. It could be a good idea to fill all of RAM with trash (e.g. 0xCCCCCCCC) during boot to help find this sort of problem....


Cheers,

Brendan

[neon]

Thanks for your response!

Actually, I havnt set up TSS yet, so your example doesnt apply:)

_Sys_IRQ_Handler() doesnt touch the stack directly. If it
did currupt the stack, wouldnt all of my ISRs not work?
ie, I dont think it would work on any machine if thats the case..

The other suggestion is to make sure you're not relying on uninitialised data somewhere. It could be a good idea to fill all of RAM with trash (e.g. 0xCCCCCCCC) during boot to help find this sort of problem....

That is a good idea Do most kernels do this?

Thanks!

[neon]

After watching the stack (with the output from my RSOD),
the stack iteself was fine. I decided to build a new GDT in
my kernel, allowing up to 4GBytes of address space.

After creating/installing the new GDT over my bootloader one,
the code works fine on PCs now

Thanks for your suggestions