'sti' cause crash.. need some help

Gnippel · Post by **Gnippel** » Tue Mar 06, 2007 7:14 pm

Hello!

I have ha little problem..
When i try to enable interrupts the whole kernel crashes..
The sources i'm using are from one of the tutorials i found here,
except from a few non-important changes, so i can't figure what's wrong.. :s

i'm using msvc, maybe that's where the problem lies? .. a setting i've missed maybe?
i'm 110% shure that it's possible to use msvc to program a kernel in so don't start to flame me because of that...

i've attached the sources so please take a look and see if you can figure out what's wrong.

and please, don't start to assume anything whitout looking at the sources or testing them first.

Thanks!

~ · Post by ~ » Tue Mar 06, 2007 7:18 pm

Could you please attach the binaries as well?

Gnippel · Post by **Gnippel** » Tue Mar 06, 2007 7:57 pm

shure!

a floppy image is included too..
with grub.. so you will have to type:
kernel /kernel.exe
boot

but i'm shure you know that from before..

anyway, here you go..

note: i had to use winrar because attach limit here is 64 kb.
zip produced 65 kb.. :/

iammisc · Post by **iammisc** » Tue Mar 06, 2007 9:04 pm

are all your idt entries filled?

Gnippel · Post by **Gnippel** » Tue Mar 06, 2007 9:18 pm

iammisc wrote:are all your idt entries filled?

jupp..

and please, don't start to assume anything whitout looking at the sources or testing them first.

hmm.. if you had looked you would have seen that they are filled..
i'm afraid that i'm repeating myself, but take a look at the sources before you ask..
i need Help, not questions...

thanks

os64dev · Post by **os64dev** » Wed Mar 07, 2007 12:31 am

gnippel wrote:hmm.. if you had looked you would have seen that they are filled..
i'm afraid that i'm repeating myself, but take a look at the sources before you ask..
i need Help, not questions...

Loose the attitude, most problems are solved by asking questions. People have their own projects to worry about and you should be glad someone is responding to you problem

Ok now the solution, maybe. I didn't fully look in to the source code but looking at the isrs i saw that all the isrs push two values. well this is wrong because some interrupts also push an errorcode so those should have at least 1 push less, see either the intel or amd manuals. so problably the crash is because of stack corruption.

hope this helps.

Gnippel · Post by **Gnippel** » Wed Mar 07, 2007 9:12 am

os64dev wrote: Loose the attitude, most problems are solved by asking questions. People have their own projects to worry about and you should be glad someone is responding to you problem

sorry about that.. i was really tired yesterday.. no harm done, i hope

os64dev wrote: Ok now the solution, maybe. I didn't fully look in to the source code but looking at the isrs i saw that all the isrs push two values. well this is wrong because some interrupts also push an errorcode so those should have at least 1 push less, see either the intel or amd manuals. so problably the crash is because of stack corruption.

hope this helps.

No, They are correct. 0-7 push two, 8 push one, 9 push two etc...

Any other ideas?

Combuster · Post by **Combuster** » Wed Mar 07, 2007 9:46 am

there's more going on...
bochs fails, apparently without getting anywhere...
(I get the same message from qemu)

Code: Select all

Woops! System Halted!

General Protection Fault

with this in the log:

Code: Select all

00393491593e[CPU0 ] check_cs: not a valid code segment !
01319604000p[WGUI ] >>PANIC<< POWER button turned off.
01319604000i[SYS  ] Last time is 1173282622
# In bx_win32_gui_c::exit(void)!
01319604000i[CPU0 ] protected mode
01319604000i[CPU0 ] CS.d_b = 32 bit
01319604000i[CPU0 ] SS.d_b = 32 bit
01319604000i[CPU0 ] | EAX=00000018  EBX=00000000  ECX=00000108  EDX=000b03d5
01319604000i[CPU0 ] | ESP=00103f89  EBP=00067f2c  ESI=00102060  EDI=00103f95
01319604000i[CPU0 ] | IOPL=0 id vip vif ac vm rf nt of df if tf sf ZF af PF cf
01319604000i[CPU0 ] | SEG selector     base    limit G D
01319604000i[CPU0 ] | SEG sltr(index|ti|rpl)     base    limit G D
01319604000i[CPU0 ] |  CS:0008( 0001| 0|  0) 00000000 000fffff 1 1
01319604000i[CPU0 ] |  DS:0010( 0002| 0|  0) 00000000 000fffff 1 1
01319604000i[CPU0 ] |  SS:0010( 0002| 0|  0) 00000000 000fffff 1 1
01319604000i[CPU0 ] |  ES:0010( 0002| 0|  0) 00000000 000fffff 1 1
01319604000i[CPU0 ] |  FS:0010( 0002| 0|  0) 00000000 000fffff 1 1
01319604000i[CPU0 ] |  GS:0010( 0002| 0|  0) 00000000 000fffff 1 1
01319604000i[CPU0 ] | EIP=0010143c (0010143c)
01319604000i[CPU0 ] | CR0=0x00000011 CR1=0 CR2=0x00000000
01319604000i[CPU0 ] | CR3=0x00000000 CR4=0x00000000
01319604000i[CPU0 ] >> jmp .+0xfffffffe (0x0010143c) : EBFE
01319604000i[     ] restoring default signal behavior

Try finding your far jumps, far calls, irets and see where they go: either the GDT is corrupted (which can potentially be GRUB's), or you messed up the stack.

Gnippel · Post by **Gnippel** » Wed Mar 07, 2007 10:39 am

Combuster wrote: Try finding your far jumps, far calls, irets and see where they go: either the GDT is corrupted (which can potentially be GRUB's), or you messed up the stack.

There is only one far jump. it's set up like this:
db 0eah
dd flush2
dw 08h

wich is the same as jmp 0x08:flush2.

i've suspected that it has something todo with the GDT but i can't find anything wrong there..

it crashes right after this:
__asm sti;
for(;;);

if i comment out 'sti' it works fine but keyboard won't work.
and keyboard is something that is Far from useless in kernel dev..

what did you mean with "which can potentially be GRUB's" ?
i do load a new gdt if that's what's you hinting to.

how can i figure if i've messed up the stack?

thanks

Mikae · Post by **Mikae** » Wed Mar 07, 2007 11:22 am

Does your code, executing 'sti' running at privelege level 0?

Gnippel · Post by **Gnippel** » Wed Mar 07, 2007 11:56 am

Mikae wrote:Does your code, executing 'sti' running at privelege level 0?

yes, everything is running at 0.

~ · Post by ~ » Wed Mar 07, 2007 12:53 pm

I'm pretty sure it has nothing or practically nothing to do with GRUB because it can be booted by other means. It looks like is more something in the kernel, but it requires to patiently understand what each part of the source is really doing.

Gnippel · Post by **Gnippel** » Wed Mar 07, 2007 1:43 pm

the sources are 99% of what you'll find in this tutorial:
http://www.osdever.net/bkerndev/index.php

except from a couple things that i had to change to make it work with msvc..

the only thing that i can think of that's causing the crash might be this:

#include <PshPack1.h>
struct gdt_entry
{
unsigned short limit_low;
unsigned short base_low;
unsigned char base_middle;
unsigned char access;
unsigned char granularity;
unsigned char base_high;
} /*__attribute__((packed))*/;
#include <PopPack.h>

PshPack1.h does the same thing as '__attribute__((packed))' right?
turn on 1 byte packing alignment?

i've tried to use pshpack 2 and 4, and also only using different #pragma pack option.. no change..

so i have no clue.. i've tried everything i can think of..
i'm shure it's just a small thing i've missed.. but what..

any other ideas?

thanks

Combuster · Post by **Combuster** » Wed Mar 07, 2007 2:17 pm

Gnippel wrote:
iammisc wrote:are all your idt entries filled?
jupp..

nope..
you forgot to fill in the idt entries used by the PIC: Once it receives an interrupt (probably IRQ0 from the timer) it'll add the base vector and send this number to the processor, causing an int 0x20 (which happens to be all zeroes allowing the processor to bail out to the GPF handler).

Gnippel · Post by **Gnippel** » Wed Mar 07, 2007 2:35 pm

Combuster wrote:
Gnippel wrote:
iammisc wrote:are all your idt entries filled?
jupp..
nope..
you forgot to fill in the idt entries used by the PIC: Once it receives an interrupt (probably IRQ0 from the timer) it'll add the base vector and send this number to the processor, causing an int 0x20 (which happens to be all zeroes allowing the processor to bail out to the GPF handler).

do you mean 'isrs_install();' ?

i've put that in idt.c in 'idt_install()'.. just before:
__asm lidt fword ptr [idtp];

take a look in idt.c and you'll see.
but i've put that back where it originaly was in the tutorial..
but that didn't affect anything..

now i've changed everything back so it's 100% the same as in the tutorial
except from the multiboot header..
and, what i said in one of my last posts, the pshpack thingy..

still getting the same crash..