Keyboard freezes in user programs (TBOS32)

[Troy Martin]

Hi all,

I'm currently developing a partial C library for users to use when developing for TBOS32. The programs are currently loaded from the ramdisk to 0x200000 and executed in kernel mode.

However, I've hit a snag. Whenever a program executes any keyboard-related function, the keyboard fails to respond. Now, this could be a fault on behalf of the system call ISR, but at this stage, I'm just going to give in and post here.

The source is browsable at http://www.quokforge.org/projects/tbos3 ... owse/trunk. I'm thinking it's either in core/isr.s, core/keyboard.c, and/or user/lib.c. But you don't really want to look at user/lib.c for too long without a barf bag or a couple of Gravol pills nearby.

Thanks for any advice/fixes,
--Troy

[pcmattman]

Your system call ISR doesn't enable interrupts, so your wait_key function hangs forever (because the buffer position will only change when an IRQ fires and a key is added to the buffer).

[Troy Martin]

D'OH!

Thanks, Matt, I'm sure that will fix it. I should have known it was that kind of stupid error. Thanks again!

Lesson to all: make sure you enable interrupts before using your keyboard IRQ. Otherwise you get a problem that makes you feel really stupid when someone tells you what the fix is

--Troy

[Firestryke31]

I believe there's a thread for things like this...

[Troy Martin]

I hereby retract my "D'OH". That didn't seem to fix it. I changed my syscall interrupt code like so:

Code: Select all

isr54:
    sti
    cmp eax,NUM_SYSCALLS
    jae .invalid_num
    
    push edi
    push esi
    push edx
    push ecx
    push ebx
    
    call dword [syscall_table+eax*4]
    
    pop ebx
    pop ebx
    pop ebx
    pop ebx
    pop ebx
    
    iret
    
.invalid_num:
    mov eax,0xFFFFFFFF
    iret

Unless my assembly's that horribly rusty, I still don't have a clue what's the problem!

[Combuster]

Did you ever get interrupts from the keyboard? (there's a FAQ entry listing a hundred-and-one causes for that)

[Troy Martin]

Oh, yeah, keyboard works perfectly fine in the kernel. Just not when used from the user programs (<flameguard>in kernel space.</flameguard>)

[pcmattman]

Probably not the cause of the problem, but...

Code: Select all

isr54:
    sti
    cmp eax,NUM_SYSCALLS
    jae .invalid_num
    
    push edi
    push esi
    push edx
    push ecx
    push ebx
    
    call dword [syscall_table+eax*4]
    
    pop ebx
    pop ebx
    pop ebx
    pop ebx
    pop ebx
    
    iret

If you want to take the parameters off the stack, don't trash a variable :

Code: Select all

isr54:
    sti
    cmp eax,NUM_SYSCALLS
    jae .invalid_num
    
    push edi
    push esi
    push edx
    push ecx
    push ebx
    
    call dword [syscall_table+eax*4]
    
    add esp, 20
    
    iret

EDIT: Looking at user/lib.c, does wait_key work by itself, outside of get_string? I'd make sure that it's all working before you put it in another function.

[Troy Martin]

Hehe, more wonderful little d'oh moments and fixes.. Thanks, matt, but I still have my first problem

--Troy

[pcmattman]

Okay, I suggest you use the Bochs debugger then.

Start it up, hit the "CONFIG" button, and then change the KBD device log options to "debug". When you see the same behaviour, hit CTRL-C on the console to see the general area that it's executing. Quit the debugger, read the bochsout, and look for anything out of order. Finally, find out what's at the address you got from the debugger, and then figure out why it was there. Repeat until you have a good idea of what's causing your bug.

[NickJohnson]

Did you make sure interrupts are still enabled in your "user" program? Just push EFLAGS print it, and check for the presence of IF. Your interrupt handler doesn't make sure interrupts have been enabled when it returns, just that they are the same state as before (which is good imo, but would allow the problem to happen).

[pcmattman]

Thanks, matt, but I still have my first problem

I checked out your SVN repository, added a sti to the system call ISR, and avoided trashing EBX, and "testapp.bin" ran without a hitch. What's the problem?

[Troy Martin]

Really? I made those changes and it still freezes in wait_key or getch or whatever it uses...

What are you testing in? It fails in QEMU and Bochs over here.

Code: Select all

isr54:
    sti
    cmp eax,NUM_SYSCALLS
    jae .invalid_num
    
    push edi
    push esi
    push edx
    push ecx
    push ebx
    
    call dword [syscall_table+eax*4]
    
    add esp,20
    
    iret
    
.invalid_num:
    mov eax,0xFFFFFFFF
    iret