Strange problem with interrupts

[Chandra]

Hello everyone,

Recently I encountered a strange problem while testing my kernel under real hardware. The problem is when I detach the ps2 mouse, my kernel would halt while trying to enable the interrupts after setting up idt. Now if I replug my mouse then everything goes well and there is no halt problem. To make sure nothing interfieres with my mouse I removed the mouse handler code completely but still same problem. If anybody know why is this happening and if anybody have workaround for this, please help.

[~]

There could be an infinite loop polling a condition that is not well designed somewhere. But without seeing all of te related code, not much can be done.

It would be better to rewrite possible related polling infinite loops, making them simpler until the problem is fixed.

Or better yet, make a test kernel or small DOS .COM program with only the necesary "polling" code, and integrate it until you devise a correct algorithm, and so on for every part of your kernel. Otherwise it will be a long time for maybe only fixing a secondary bug of another bug that anyway will probably need a fuller rewrite.

[Brynet-Inc]

Hello everyone,

Recently I encountered a strange problem while testing my kernel under real hardware. The problem is when I detach the ps2 mouse, my kernel would halt while trying to enable the interrupts after setting up idt. Now if I replug my mouse then everything goes well and there is no halt problem. To make sure nothing interfieres with my mouse I removed the mouse handler code completely but still same problem. If anybody know why is this happening and if anybody have workaround for this, please help.

PS/2 devices are NOT plug and play, even if it "sometimes" works on some systems.. while you may be able to make your driver workaround these events, it's generally undefined behaviour.

[Gaidheal]

^ Aye, this. I remember a couple of systems, when I was younger, that would lock up (in Windows) if I pulled the PS/2 mouse. I discovered it because of my naive assumption that they were PnP, as alluded to above. Most other PCs I have used seem to gracefully handle it by removing the device (and will, of course, not replace it if you plug it back in) but as Bry says, I don't believe the standard defines behaviour for this; you're not meant to remove the devices with the machine powered.

[Chandra]

Oh, sorry. I think you people are not getting what I was talking about. May be my post was not clear or so. Let it be. Rather than editing my post, let me make things clear.

I was no way talking about the plug and play system of ps2 mouse. Every time, I detach or attach my mouse that was after the computer was shutdown. I mean I was not plugging and unplugging my mouse while my kernel was running. If you are not still getting this assume yourself in place of me.
1. You write a kernel which works fine with the emulator.
2. You decide to test your kernel under real hardware to see if there is any bugs.
3. You test your kernel under real hardware and everything goes fine.
4. Now you shutdown the computer and then detach the ps2 mouse.
5. You restart your computer and run your kernel again under real hardware(This time without the ps2 mouse).
6. Suddenly, your kernel freezes in the middle of something (which did not happen when the ps2 mouse was plugged in).

This is exactly what is happening to me. After, long test I found that the problem occurred when I was trying to enable the interrupts(when the ps2 mouse was not plugged in). Again, if the ps2 mouse was plugged in back to the port and if I restart my pc to test my kernel, then there would be no problem at all. I know what is causing problem but not why.

@ ~ : There's no infinite loop in my kernel and my kernel runs very well when the ps2 mouse is attached to the port. Now for the code, it is too big to post it here. And I think It is going to annoy some people over here. So let me not do that. Anyway, the fun part is since my kernel freezes at the very beginning here's the code of that first part:

Code: Select all

void kernel_main()
{
disable_interrupts();
idt_install();
isrs_install();
irq_install();
timer_install();
keyboard_install();
enable_interrupts();    /*This is the point which is causing the problem when ps2 mouse is not plugged in*/

/* a lot of code then..... */

}

Note that this problem will not occur when I insert the ps2 mouse in the ps2 port. But if I shutdown the computer, detach the ps2 mouse , restart the computer and test under real hardware then at the very point where the interrupts are enabled, the kernel freezes.

I hope anybody out there will be able to help me. Thank you all.

[Gaidheal]

Code for that "enable_interrupts()" function might be useful.

[rdos]

I was no way talking about the plug and play system of ps2 mouse. Every time, I detach or attach my mouse that was after the computer was shutdown. I mean I was not plugging and unplugging my mouse while my kernel was running. If you are not still getting this assume yourself in place of me.
1. You write a kernel which works fine with the emulator.
2. You decide to test your kernel under real hardware to see if there is any bugs.
3. You test your kernel under real hardware and everything goes fine.
4. Now you shutdown the computer and then detach the ps2 mouse.
5. You restart your computer and run your kernel again under real hardware(This time without the ps2 mouse).
6. Suddenly, your kernel freezes in the middle of something (which did not happen when the ps2 mouse was plugged in).

I know about this problem. I've had it a long time in my keyboard driver as well. As far as I have figured this problem out, something goes wrong with the keyboard IRQ when accessing some mouse-related function when there is no mouse. I've solved this by having two different drivers. One with mouse support and one without. The thing is, this does not really "hang" the system. It only makes the keyboard malfunction. At least in my OS. The command prompt comes up ok, remote debugging works, but the keyboard is not working.

So, if you find a solution to this, I'd be interested in what you actually did to eliminate it.

Edit: if the system "locks up" on the enable IRQ (instead of the keyboard just malfunctioning), mostly likely there is an IRQ-loop where some IRQ is not handled properly and instead is reentered indefinitely.

[Chandra]

I suppose that the interrupts handler is fine because I have removed everything (including the mouse handler) except the original one from Bran's Kernel Development Tutorial. I infact did modify his handlers to great extent but now I have reverted everything to his original. But still same problem. To make sure everything is correct, I have removed removed everything from my kernel to make it primitive but I've been encountering same problem. Right now, I've been trying to figure out what is causing the problem so when I succeed, I'll post here.

[gerryg400]

I have a few ideas. Firstly, if your OS is halting it is possibly (likely) stuck in a loop somewhere. This has happened to me at least 3 times recently.

1) Do you have spinlocks ? And if so are they interrupt safe ? I thought mine were okay but I had a temporary spinlock in my kprintf that was not. Sometimes when I tried to kprintf from an isr, if the lock were already held outside the isr, I would spin forever.

2) Do you have any while (1); in temporary code. I had a spurious isr that would be fired on interrupts I didn't expect. It was supposed to print to the screen but had a bug caused it to loop before printing to the screen

3) Does your keyboard handler spin while reading port 0x64. I have had PCs lock up with code like this (from the wiki)

Code: Select all

while((inportb(0x64)&2)!=0){}

It's much better to do this

Code: Select all

    long cnt = 100000;

    while (c  && --cnt) {
        c = inportb(0x64) & 0x2;
    }

Just some ideas...

[Chandra]

@gerryg400: Your logic is admirable however as I have already said the core of the problem is mouse not being there. If the mouse is plugged in to ps2 port then everything is fine. Note that I enable the interrupts at the very first part of the kernel and if no mouse is plugged in then it halts at that very first part. Now if the mouse is plugged in back to the ps2 port then everything is fine which proves that at least it is not the loop or similar thing that is causing the problem. It is obvious to me that mouse is associated with interrupts but I suppose not this way. Now so far the interrupts are concerened, they are safe because as for test purpose, whenever any interrupt fires I dump the register contents to screen and they seem to be okay.
I have managed to somehow avoid this problem by first detecting if there's mouse connected or not and then only enabling interrupts if they are connected. Otherwise my OS would bump out with error message indicating "No Mouse Connected!". But this doen't seem to be the best way to avoid this problem. Anyway, thanks for trying to help me atleast.

[rdos]

There are less obvious ways an OS can get stuck in a loop. For instance, if you enable an interrupt, you would normally need to clear it be reading some status register. Failing to do so, or just putting a default interrupt handler for unknown hardware very likely will end up in an interrupt-loop, where the interrupt service routine is reentered endlessly. The PS/2 keyboard & mouse have two different interrupts (if I remember it correctly), and rely on clearing status-bits in order to clear the cause of the interrupt.

[rdos]

@gerryg400: Your logic is admirable however as I have already said the core of the problem is mouse not being there.

That's exactly why gerryg400 has the TIMEOUT in the wait function - mouse is not there and you will not receive the status change on that register EVER. So you will have to timeout and assume the mouse is not there.

That only helps if you detect without using interrupts, which actually might be the best way to go about it. Still, if the non-existent mouse hardware generates a faulty interrupt (that cannot be cleared due to missing status-registers), the system might still lock-up once hardware IRQs for the keyboard is enabled.

BTW, is there a full-proof way of detecting the presence of the PS/2 mouse? I looked a lot for this a while ago, and read many documents, without coming out with something that might always work. Even on Windoze, if you unplug the keyboard and/or mouse, chances are they will stop working, which means there are some issues even for those that should have the best documentation.

[~]

This is an old comment from my own archives. Maybe it will help you experiment some solution. By now I'm trying to setup some more documentation and easy to understand code to upload:

Code: Select all

 ;The following 2 mouse commands are NOT intended to
 ;actually setup the mouse, but really are a workaround
 ;to detect if there is a mouse connected into the system.
 ;They should respond with a NACK byte (0xFE) in that case
 ;which will make clear to us that there is NOT a valid
 ;mouse connected to the computer and with this we avoid
 ;an error that otherwise locks the computer until we press
 ;the keyboard. If there is a mouse connected, this code
 ;should do nothing (anyway we'll be resetting the mouse).
 ;This trick works because the keyboard commands 0xE6 and
 ;0xE7 don't exist on the vast majority, standard keyboards
 ;and hopefully never in a nonstandard one. We could use as
 ;many byte values for commands unique to the mouse but that
 ;are testedly undefined for the keyboard. If we tested every
 ;byte for mouse commands that are undefined for keyboards,
 ;we could further guarantee that the mouse setup will be correct.

  mov al,0xE6                              ;Set Scaling 1:1
  call Mouse.Driver.writePort__FOR_COMMAND
   cmp al,0xFA   ;The previous call also reads the first ACK byte!
   jnz .setupPS2Mouse__ERR

  mov al,0xE7                              ;Set Scaling 2:1
  call Mouse.Driver.writePort__FOR_COMMAND
   cmp al,0xFA   ;The previous call also reads the first ACK byte!
   jnz .setupPS2Mouse__ERR


 ;If we are here, it means that there is indeed a
 ;(PS/2) mouse connected to the computer.
 ;;
 ;;;

     ...................
     ...................
     ...................
     ...................


.setupPS2Mouse__ERR:

Sending command 0xD4 to port 0x64 (and related procedures) to ensure that configuration, commands, etc., will go to the mouse instead to the keyboard.

Code: Select all

Mouse.Driver.writePort__FOR_COMMAND:
 push ebx

 mov bl,al   ;Save original intended command
   mov al,0xD4  ;Keyboard Controller Command: WRITE TO MOUSE
    ;call Keyb.Controller.writeCmdPort
    ;;
     out 0x64,al

 mov al,bl   ;Restore original intended command
  ;call Keyb.writeCmdParamPort
  ;;
   out 0x60,al


 ;;Read the first ACK of a possible Multi-ACK:
 ;;
 ;;;
   ;call Keyb.readACKPort
   ;;;
    in al,0x60

 pop ebx

ret

http://www.win.tue.nl/~aeb/linux/kbd/sc ... tml#ss11.3
http://www.win.tue.nl/~aeb/linux/kbd/scancodes.html