OSDev.org

The size reserved for each architecture can be easily configured by putting a struct within the thread struct. The size required doesn't really matter overall as the difference is that all the memory is actually used and the only performance difference being the requirement to move ESP back and forth twice, only on entry and exit from the scheduler.

hi guys
again the problem still exists
i tried to post in on fasm forums but no answer.
i've attached the bochs output file their and last modification in code.
http://board.flatassembler.net/topic.php?t=3743
thanks aklot ::)

Can you post the code for Interrupt 8?
Interrupts 8, 10, 11, 12, 13, 14 have an errorcode pushed on the stack. eg.

and please, don't cli/sti around your handler. This makes no sense at all! If you've found that in a tutorial, feel free to notify the author he shouldn't do that unless he has very good reason.

I don't either see code of yours that remaps the PIC (or maybe i missed it), which means you'll receive EXC8 18 times a second due to the fact it's aliased with IRQ0 ... Since the CPU pushes no error code when it calls the handler for IRQ0 (and it has no way to know it has conflict with double fault handler), you'll be in trouble as soon as you enable interrupts.

The things about AR (Access Rights) for CS also make me fear you somehow overwrote your GDT so that descriptor 8 no longer has the correct values.
If you have the sources of your bochs, you might want to search for that error message and instrument it so that it also returns the selector in use (so that you can actually check what's being loaded is what you expect).

i removed the cli and sti but the error still here.
i think sti and cli don't cause trouble , i've seen in a webpage that the isr should disable ints when executing an int to prevent double faults.
Pype.Clicker have u seen the bochs output.

00146296777e[CPU ] iret: AR byte indicated non code
00186885000i[CPU ] | SEG selector base limit G D
00186885000i[CPU ] | SEG sltr(index|ti|rpl) base limit G D
00186885000i[CPU ] | CS:0008( 0001| 0| 0) 00000000 000fffff 1 1
00186885000i[CPU ] | DS:0010( 0002| 0| 0) 00000000 000fffff 1 1
00186885000i[CPU ] | SS:0010( 0002| 0| 0) 00000000 000fffff 1 1
00186885000i[CPU ] | ES:0010( 0002| 0| 0) 00000000 000fffff 1 1
00186885000i[CPU ] | FS:0010( 0002| 0| 0) 00000000 000fffff 1 1
00186885000i[CPU ] | GS:0010( 0002| 0| 0) 00000000 000fffff 1 1

its very boring to have a bug and try to solve it for 3 days or more without removing it :-[

i don't know what to do, where is the error ?

Beastie wrote: i removed the cli and sti but the error still here.
i think sti and cli don't cause trouble ,

They're not, but they're wrong nonetheless.

i've seen in a webpage that the isr should disable ints when executing an int to prevent double faults.

You have different types of descriptors for the IDT that tells the CPU whether it should disable interrupts when receiving the exception or not. It will certainly not prevent double faults in general (e.g. the CPU ignores IF when delivering an exception) and it can lead to a stack overflow as you re-enabled interrupts *before* you got out of the ISR.

Pype.Clicker have u seen the bochs output.

I did. But it just tells that the "IRET" instruction has been tried from CS==0008. It tells you nothing about whether the code segment you tried to load was 0x8 aswell nor what was the content of GDT[8] at that moment.

If you can handle me a diskimage, i'll run a "bochs debugging session" and see if i can prove what i fear.

its very boring to have a bug and try to solve it for 3 days or more without removing it :-[

"Debug sessions darker than the night", would say BI

Pype.Clicker: Here is the fd image u requested
http://linuxalex.sunsite.dk/libosdk.zip

i've found something really strange, when i boot the kernel by bochs from the real hd directly it gives me the GPF but when i boot from the fd image it just panic LDTR.valid=0, on the otherhand qemu gives the same result in both cases : from real hd, from fd image, which is GPF but the cs content differ AFAIK.
i didn't prepare the fd, i just download it.
i found that grun on my machine is 0.96 while on the downloaded fd image 0.94.

ah i finally know why people kill theirselves ;D

i think my problem will be in the exampleos itself, or may be a bug in grub itself since different version of grub outputs different oputputs .

Welcome, my friend, to debug sessions darker than night!
Be my guest, but remember ....

Debug or Die *mwahahahahahaaa*

Sorry, I just couldna resist.

You won't imagine how long I've hunted after an utterly obscure bug in my paging code - just to find out that it's been as simple as zeroing out that *damned* page tables in order to have them in a clean - virgin - state. Guess. 5-6 Months. But don't worry, I haven't got even the slightest hankering for a kill. You see, I'm still around *gg*.And in the meantime I've just developed and coded on. Sooner or later it *needed* to show up in a fairly debuggable fashion. FOr god's sake that's been last year. Now I'm searching for - GUI BUGS *aaarrrgh* and vm86 BUGs *whamwham*last chr...*

I just can give you a hint: lock out all the interrupts. disable them in hardware. Then debug your interrupt/exception stuff with one and only one interrupt. The keyboard interrupt, as you are in control of it.

BTW from the looks of your bochs output it looks as if you're trying to pop something not being a code segment off the stack upon iret. Maybe you've screwed up some push/pop order or some crucial nitty gritty in your task setup stuff (especially the stack preparation)

To cheer you up: this interrupts stuff - once you've sorted it out and got it working - it works and you can go on to funnier things.

Stay safe.

i've checked the ISR , i don't think there is a problem in them. it may be the exampleos that i used to test them or something to do with grub or multiboot.
it acts differently on different versions of grub.
do i've to set IDT before GDT ?

Pype.Clicker about using cli and sti in interrupt handle code.
The only reason for doing this is because he could have used trap gates and not interrupt gates ???

Intel docs info about this:
[tt]
The only difference between an interrupt gate and a trap gate is the way the processor handles
the IF flag in the EFLAGS register. When accessing an exception- or interrupt-handling procedure
through an interrupt gate, the processor clears the IF flag to prevent other interrupts from
interfering with the current interrupt handler. A subsequent IRET instruction restores the IF flag
to its value in the saved contents of the EFLAGS register on the stack. Accessing a handler
procedure through a trap gate does not affect the IF flag.
[/tt]

Hm. grub is supposed just to load the kernel and jump to it.

Just stick to the latest version.

There is no constraint about what to load first - gdt or idt. But usually,we load the gdt first. As long as irqs remain disabled and you dont trigger exceptions, you shouldn't have trouble with loading the idt first.

>Hm. grub is supposed just to load the kernel and jump to it.
And set A20 , jump to protect mode pointing cs to code segmnet with base 0 and limit 4gb and ds with data segment with base 0 and limit 0.
>Just stick to the latest version.
Then why 0.94 acts different than 0.96 ?