OSDev.org

Nable wrote:> Any ideas as to whats going on here?
Some race condition in your code (although there's a very little but non-zero probability of bug in Bochs, about 2 years ago I've found a reproducable bug^W strange behaviour on invalid code that nobody could debug).

> call Thread_Lock
> pop dword[IOPort_Read_8_Return] ;Save the return address
Why are you doing this? You have too little stack space? This is not ARM with its link-register, so you don't have to save return address before calling another routine.
So, just use [esp+4] memory access.

> push eax
So, you are replacing the argument on stack with return data. Why are you using such a strange calling convention?

I don't know how good is your implementation of Thread_Lock but you are definitely doing things in a strange way.
(btw: avoid pop'ing return address, each 'call' should have its 'ret', else processor's call trace optimizations won't work)

PearOs wrote:If I set the PIT to run super faster, no issues. My code gets called, nothing crashes, I can switch tasks, the works. But the second I pressed a ton of keyboard keys, Bochs prints out "fetch_raw_descriptor: LDTR.valid=0" and it doesn't always happen. I can press a ton and it never happens and then it does. But whats odd is if I set the PIT to a slower speed and do that it takes a much longer time to actually cause a crash. But here's the annoying part, the keyboard code is super basic. I pretty much wiped it to nothing thinking it was a issue with the stack. I don't think it is.

Brendan wrote:Hi,

PearOs wrote:If I set the PIT to run super faster, no issues. My code gets called, nothing crashes, I can switch tasks, the works. But the second I pressed a ton of keyboard keys, Bochs prints out "fetch_raw_descriptor: LDTR.valid=0" and it doesn't always happen. I can press a ton and it never happens and then it does. But whats odd is if I set the PIT to a slower speed and do that it takes a much longer time to actually cause a crash. But here's the annoying part, the keyboard code is super basic. I pretty much wiped it to nothing thinking it was a issue with the stack. I don't think it is.

I'd be tempted to assume that your PIT IRQ handler trashes some registers. When not much is happening the PIT interrupts "not much" and trashes a register that wasn't being used anyway; but when PIT interrupts the keyboard's IRQ handler the register is being used and causes the keyboard's IRQ handler to crash in some strange (potentially "random" way).


Cheers,

Brendan

irq_int: dd 0
irq_common_stub:
pop dword[irq_int]

mov byte[0xB8000], '0'

;Save all the registers
;to the stack
;pushad
push eax
push ebx
push ecx
push edx
push ebp
push edi
push esi
push esp
;Prevent interrupts from being
;started again
call Thread_Ignore
;Try to save the current stack
;to the thread running
;mov eax, esp
;push eax
;call iPear.Multitasking.Core.SaveStack_U32
;Now try to run Masked IRQ's
push dword[irq_int]
call iPear.Hardware.IRQ.Invoke_U32

.skip:
;Now attempt to switch threads
;if we can.
;call iPear.Multitasking.Core.Switch
;pop eax
;cmp eax, 0
;je .end ;Not a valid stack
;Otherwise set our new stack
;mov esp, eax

.end:
;Now send our end of interrupt
mov eax, dword[irq_int]
add eax, 32
push eax
call PIC_EOI
;Now unignore threads
call Thread_UnIgnore
;Ok now we have to restore all the registers.
;popad
pop esp
pop esi
pop edi
pop ebp
pop edx
pop ecx
pop ebx
pop eax
;Restore interrupts.
sti
;Now just return.
iret

Combuster wrote:You realize what IRET does to IF?

Antti wrote:If interrupts are disabled before executing an interrupt handler (e.g. software interrupt triggered) and we want to enable them, executing "sti" before "iret" could actually make sense. I have not tested it but "interrupts are enabled at the end of the next instruction".

or [esp + 8], 0x200
iret