OSDev.org

I am writing a simple kernel for multiboot spec (ie which can be loaded from Grub). The kernel is compiled as ELF file. This simple kernel just display some text on the screen (via 0xB000 video area), and wait for the keyboard to be pressed (read from 0x60 port), then reboot the machine. It doesnt do anything with GDT or IDT at all. So far it works well.

Now I make a simple change to the code: I add 2 lines like this:

cli
sti

The reason I want to add these because, I want to setup the GDT for the kernel: actually the GDT setup code will be inserted between CLI and
STI. The problem is that my kernel now, with only 2 above lines, crashes.

Anybody have any idea why adding CLI and STI (immediately behind CLI)
into the code makes the kernel crash? Even better, what should I do to fix it?

I looked at the Multiboot spec documentation, but dont see anywhere mention or any caution about this.

I am really stuck here. All the help are very much appreciated!

Many thanks,
Jun

PS. I think this is not relavant, but does no harm to know: I compiled my ASM code with Nasm, and link with other objs using "ld" of Linux.

A lot of thanks,
Jun

first off, try eleminating all possible causes. take out literally everything (after you back everything up first) and then try just the CLI;STI; and see if it still crashes.

Do you use bochs as your emulator? if so, you might want to go through the log and see when exactly it crashes, it may have nothing to do with the interrupts at all, you may be messing up whilst writing to memory or write/reading with ports.

are interrupts enabled prior to the cli?

01000101 wrote:first off, try eleminating all possible causes. take out literally everything (after you back everything up first) and then try just the CLI;STI; and see if it still crashes. ..... you may be messing up whilst writing to memory or write/reading with ports.

The point is that without CLI;STI my kernel works perfectly! Only when I added those insns, my kernel crashes.

Do you use bochs as your emulator? if so, you might want to go through the log and see when exactly it crashes, it may have nothing to do with the interrupts at all,

No, I use qemu to run my kernel, and it works well. I suppose that qemu is fine for my development.

But as the kernel reboots, it left no logging or error messages. Is there any way to get that information with qemu?

To make it more clear, I boot my kernel via Grub 0.97. Grub loads the kernel from Linux filesystem (but that doesnt matter, I think)

Combuster wrote:are interrupts enabled prior to the cli?

It is supposed to be disabled before CLI, as in Multiboot spec. (the spec says that when the kernel is given the control, the IF is cleared)

But I think that is not the cause of the problem, as CLI shoud do no harm if IF is already cleared, right??

Thanks,
Jun

It is supposed to be disabled before CLI

It means that the net effect of the code is that it enables interrupts.
Have you got an IDT yet?

Combuster wrote:

It is supposed to be disabled before CLI

It means that the net effect of the code is that it enables interrupts.
Have you got an IDT yet?

No, not yet!!!

Is that the cause of the problem? What do you mean by the "net effect of enabling interrupts"? Why CLI/STI would make the system unstable, why we doesnt not make any interrupt at all?

So in case I must set up IDT to avoid the problem, exactly which interrupts must be programmed? (minimum requirement)

Many thanks,
Jun

Hi,

You need an IDT before enabling interrupts. At minimum, you will need interrupts 0-31 (the CPU exceptions) and will need 16 entires for IRQ's (you can mask off the PIC's, but I would still suggest having those entries there before STI).

Cheers,
Adam

AJ wrote:You need an IDT before enabling interrupts. At minimum, you will need interrupts 0-31 (the CPU exceptions) and will need 16 entires for IRQ's (you can mask off the PIC's, but I would still suggest having those entries there before STI).

Perfect! So I guess this is the problem of my bug

So I think because I have no IDT setup yet, some interrupts were generated after STI, and it crashes the kernel. But which kind of interrupts caused that? External interrupts? (like keyboard?)

Thanks,
Jun

Probably IRQs - specifically IRQ 0 (the PIT).

A question: actually my kernel is very simple. All it is going to do is only execute some BIOS interrupts. So is it necessary to enable interrupts with STI?

Thanks,
Jun

Yes.

Firstly, you need to STI to allow you to call BIOS interrupts. Second, you are in PMode, so for the BIOS interrupts, you will need either v86 mode (multitasking) - for which you may need a timer interrupt, or you will need to switch back to real mode each time you call a BIOS interrupt.

Can you explain what your kernel is trying to do at a higher level? That way we may be able to suggest a different way of doing it.

Cheers,
Adam

AJ wrote:Yes.

Firstly, you need to STI to allow you to call BIOS interrupts.

Is it true??? I tried to execute Int10h, and it works without having to enable interrupts (STI) at all.

Second, you are in PMode, so for the BIOS interrupts, you will need either v86 mode (multitasking) - for which you may need a timer interrupt, or you will need to switch back to real mode each time you call a BIOS interrupt.

Yes, I know that, and I did that

Can you explain what your kernel is trying to do at a higher level? That way we may be able to suggest a different way of doing it.

I am trying to execute some BIOS interrupts in my experementals kernel to see how it works. Nothing useful, just for fun! This is my first kernel ever, anyway

Lost of thanks,
Jun

junkoi wrote:

AJ wrote: Firstly, you need to STI to allow you to call BIOS interrupts.

Is it true??? I tried to execute Int10h, and it works without having to enable interrupts (STI) at all.

Hmm - I thought so but if it's working for you then I guess not...

I am trying to execute some BIOS interrupts in my experementals kernel to see how it works. Nothing useful, just for fun! This is my first kernel ever, anyway

If you just want to execute BIOS interrupts, why do you stay in PMode at all? If you drop from GRUB straight back to real mode, there is no need for an IDT and no need for STI.

If, however, you are interested in extending your kernel and staying in PMode for any length of time, then I would seriously consider adding a basic IDT.

Cheers,
Adam