Interrupts ...

[cabron]

Hi folks,

I've been experimenting with this whole low-level thing, and this is what I've got so far. Since I am too lazy to make my experiments work with GRUB or some such, I've been bootstrapping by writing my kernel as an MSDOS COM file.

The first thing it does is set to 80x25, then disable interrupts. Then it copies itself to 0000:0000 so I know where it is. Next I set up the GDT and that's all well and good, I pass a few strings to my VT100/ANSI-parsing display code. That was working out well for my ego and I, until we decided it was time to tackle interrupts.

So I set up an IDT with all 256 entries pointing to the same function: the low 16-bits of my pointer, the selector, 8E00H, and a zero word. It seems to get called just fine, as the interrupt handler can print to the console...

As soon as I re-enable interrupts I get INT 08, sometimes followed by INT 13, no matter what my kernel does, even if it's an idle loop.

This worried me, because as far as I've read, INT 08 and INT 13 can be very bad. But then I read about the default PIC mapping overlapping these Very Bad Exceptions.

My question is... How do I tell the difference? I've read about reprogramming the PIC but I'm a little hazy on the details there... What I'd like to know first is if these are exceptions or normal IRQs. Is it ever normal to get INT 08 or INT 13 casually, when you've done nothing wrong? Is this typical?

[Brendan]

Hi,

As soon as I re-enable interrupts I get INT 08, sometimes followed by INT 13, no matter what my kernel does, even if it's an idle loop.

I'd expect that INT 0x08 is IRQ 0 still firing off 18.2 times a second - if it was a double fault it should be preceded by another exception.

INT 0x0D (or INT 13) could be IRQ 5 or a general protection fault. Usually IRQ 5 isn't used for anything during boot (not until an ISA sound card, an ISA ethernet card or something is used) so I'd assume your INT 0x08 handler is causing a problem sometimes. It's hard to tell from here...

My question is... How do I tell the difference? I've read about reprogramming the PIC but I'm a little hazy on the details there... What I'd like to know first is if these are exceptions or normal IRQs. Is it ever normal to get INT 08 or INT 13 casually, when you've done nothing wrong? Is this typical?

IRQ 8 is typical, IRQ 5 isn't typical, and general protection faults are typical (but not when you've done nothing wrong) ..

If you don't want to remap the PIC's IRQs yet, you could just mask them so that IRQs don't get to the CPU. For e.g.:

Code: Select all

     mov al,0xFF
     out 0x21,al
     mov al,0xFF
     out 0xA1,al

To disable all IRQs except for IRQ 0 you could use:

Code: Select all

     mov al,0xFE
     out 0x21,al
     mov al,0xFF
     out 0xA1,al

That way you'd still get IRQ 0x08 (and you'd be able to determine if IRQ 0x08 is causing general protection faults or not).

Sooner or later you will need to remap the PIC though...


Cheers,

Brendan

[cabron]

If it's a timer interrupt, why am I getting it exactly once?

Well, I tried the snippet and the INT 08 disappears. I haven't seen INT 13 in awhile (with ot without the snippet), I guess whatever problem I had there is now fixed.

Where can I find a good explanation of how to remap the PIC? Everything I see is just code. Am I supposed to just lift that? 'Cause I'd rather get a sense of how it's actually done...

[AR]

You only ever get one PIC interrupt unless you send an acknowledgement to the chip. Try the Wiki and search the forum, how to remap it has been asked lots of times before.

Then it copies itself to 0000:0000 so I know where it is

You're destroying the BIOS by doing this making it impossible to return to DOS or to use the BIOS to change video modes and other useful things. (Overrides 16bit IVT and BIOS data segment)

[cabron]

You're destroying the BIOS by doing this making it impossible to return to DOS or to use the BIOS to change video modes and other useful things. (Overrides 16bit IVT and BIOS data segment)

I did realize this about 16-bit interrupts, was wondering if maybe this has other harmful effects (which is why I mentioned where I loaded it in the first place)... Basically I don't care much for now, I'm only using DOS temporarily until I can read up some more on multiboot for grub, or I somehow un-lazy myself, or, if this "kernel" actually becomes worth it at some point.

Thanks very much for your input... Sorry if the thread is redundant / useless.

[AR]

On Laptops apparently the BIOS keeps running in the background without your OS' knowledge, overwriting that location may cause chaos and havoc. The BIOS is useful for "being lazy" because VESA makes it easy to change video modes without having to write a driver for every video card ever made.

[Candy]

On Laptops apparently the BIOS keeps running in the background without your OS' knowledge, overwriting that location may cause chaos and havoc. The BIOS is useful for "being lazy" because VESA makes it easy to change video modes without having to write a driver for every video card ever made.

I suspect that on all recent computers, the computer will continually use SMM for BIOS-ish stuff, including handling the power button and so on. If you could disable that you could completely terminate the BIOS stuff, but I'm not sure you really want that since I suspect that stuff also to be responsible for ACPI handling (as in, translating the acpi commands to physical commands). Anybody know more about SMM / SMI's here?

[Brendan]

Hi,

I suspect that on all recent computers, the computer will continually use SMM for BIOS-ish stuff, including handling the power button and so on. If you could disable that you could completely terminate the BIOS stuff, but I'm not sure you really want that since I suspect that stuff also to be responsible for ACPI handling (as in, translating the acpi commands to physical commands). Anybody know more about SMM / SMI's here?

I know that SMM is used to make USB mouse & keyboard emulate PS/2 devices, and for APM. I expect that it's also used for ACPI, but I'm not so sure here as ACPI is meant to be controlled by the OS (where APM was meant to be hidden from the OS). It also seems to be tied up with upgrading flash BIOS's on some motherboards too.

For more information on USB keyboard & mouse see:
http://www.microsoft.com/whdc/device/input/usbhost.mspx

I'm not sure what else it is used for, but I guess this is up to the BIOS/motherboard/chipset manufacturers. It worries me a bit because I want complete control and haven't been able to find many details.


Cheers,

Brendan