STI doesn't work [SOLVED]

[System123]

I figured out why my Floppy driver never loads. It has nothing to do with the Driver but rather the fact that sti just causes my kernel to hang. I initialise my IRQ, ISR, IDT, GDT, TIMER and KEYBOARD all before I run sti but it just hangs there. I have tried both inline ie:

Code: Select all

asm
sti
end;

and external commands in a separate asm file but both just hang. Please help

[jal]

sti just causes my kernel to hang. Please help

You do not explain at all at what point the kernel 'hangs', and why you think sti causes this. In order to provide you with an answer, you really need to elaborate a bit.


JAL

[System123]

I said when sti I is executed the kernel hangs. It initializes the GDT, IDT, IRQ, Timer, ISR, Keyboard and Screen properly then I have

asm
sti
end;

and no more execution takes place. It works fine in BOCHS but on a real pc it does not. I have tested it on 3 computers.

I have know idea what could be causing this because all I have done is add a floppy driver. Before that it worked. and it can't be the floppy driver code because it doen't get as far as that in execution. I have a PrintString command before it attempts to load the floppy.

[JamesM]

I said when sti I is executed the kernel hangs. It initializes the GDT, IDT, IRQ, Timer, ISR, Keyboard and Screen properly then I have

asm
sti
end;

and no more execution takes place. It works fine in BOCHS but on a real pc it does not. I have tested it on 3 computers.

I have know idea what could be causing this because all I have done is add a floppy driver. Before that it worked. and it can't be the floppy driver code because it doen't get as far as that in execution. I have a PrintString command before it attempts to load the floppy.

Have you thought that you may be receiving a floppy IRQ or other spurious IRQ and your handling code is faulty?

[System123]

I have checked that because if an IRQ occurs that does not have a handler the handler stub returns it to continue execution.

[System123]

I hav sat up most of the night trying to find the problem. I reprogrammed my IRQ and IDT and I made sure I did not make any mistakes. I am using Brans Kernel Tutorial and converting it into Pascal.

I then ran the kernel in BOCHS and everything worked fine but when I ran it on a pc it froze again the funny thing is that my keyboard was working now which means the interrupts must of been enabled? Does this mean I could have a fault in my timer code because that is the only other thing I initialize?

[Combuster]

Do you print all exceptions to the screen so you can diagnose them?
Have you disabled the timer when enabling the keyboard?

[System123]

Ok I found the problem its my PC The Kernel does not freeze when it runs STI it just never executes anything else in the main procedure that comes after STI. But the keyboard and the timer work fine.

I tried to boot another persons Operating system which I have the source for and theirs also never executes anything after sti.

Is there a way around this so I can get my kernel to continue with the set up.

[AJ]

What OSes does your PC run? If you have ever run Linux or Windows successfully, for example, I can guarantee that their source has an STI in it somewhere. If your PC doesn't hang with commercially available OSes (for want of a better expression), then it is your OS that is at fault.

There are a few people on here familiar with Pascal. Any chance of seeing your main routine, or you uploading your source?

Just a thought, but if no other code in your main function is run after STI, but IRQ's are firing from the keyboard and timer, has your stack become trashed in an IRQ resulting in not returning properly to main?

Cheers,
Adam

[System123]

It runs linux and windows and brans kernel. But I obtained a pascal kernel from someone on this site but that doesn't work either.

Here is a link to my source code.

http://code.google.com/p/gizmicos/downloads/list

I have looked through it a lot to try find what is going wrong but I can't see anything.

[inflater]

Just for fun - try setting bigger stack. I had some weird problem that my OS ran fine on Bochs, QEMU, even MS VPC - but not on my testbed - instant freeze on one initialization part...

I know that STI doesnt have anything with the stack, but if you say that you added a floppy driver to your OS and before it, it did work, maybe it has something with the kernel's executable size vs. stack size and all.. BTW if you're using your own bootloader check that the whole kernel executable is loaded, not only the part of it.

[System123]

I know that STI doesnt have anything with the stack, but if you say that you added a floppy driver to your OS and before it, it did work, maybe it has something with the kernel's executable size vs. stack size and all.. if you're using your own bootloader check that the whole kernel is loaded, not only the part.

Yes I know I said that before hand it was working but that is because I didn't have any code after sti. I removed the floppy driver and put a clearscreen command in and that didn't even execute. So it has something to do with the kernel never getting passed sti.

[JamesM]

The STI instruction cannot "not work". It's a pretty simple instruction - I think the general answer of PEBKAC works in this case.

Have you tried accessing a bad address after your STI to check for page faults? To me, it sounds like your interrupt handlers aren't returning at all.

[Troy Martin]

I'll skim over your source after I get home. Stack size might be an issue somehow though..

[System123]

I have tried however no ISR returns. I have also tried divide by 0 and I never get an exception. Is this because interrupts aren't returning? What would be the cause to such a problem?