problems with idt kernel

[_adeelmahmood]

hi
i m having alot of problems to setup my IDT
i was checking out this IDTKernel at
osdev.neopages.net
and it worked fine until i tried to unmask the IRQ's ..
then it would just give a General protection fault and
then resets.. could some one look at this code and tell me why we cant unmask the iRQ's
also could some one show me a link to task switching
tutorials
thanx for ur help

[stonedzealot]

I second that, I had problems with it too...it just restarted the computer, nothing else...

[distantvoices]

*gg*
I took this idt-kernel at osdev.neopages.net as reference. I had to get my kernel thing with idt work before - to understand the nitty gritty of this thing.

If you get a general protection fault and the kernel resets, your idt is either not present or the entries in the idt point to nowhere.

Remember: The Idt is an array pointed to by a structure:

idtptr:
unsigned short limit;
unsigned long base;

You pass a pointer to this structure to the cpu via lidt [pointer_to_idtr]-> this means, you tell just the adress where idtptr lies, to the cpu.

If an interrupt comes along, the cpu first looks in idtr pointed to by pointer_to_idtr, and then picks the proper interrupt gate via irq-NR (the range of this nr you tell the PIC in initialization). Say irq 1 happens and irq 1 is mapped to 0x20 -> cpu takes idt entry at selector 0x20.

In the IDT entries you have to tell the cpu, where the irq-routines are, so that it finds them.

So check: ARe the entries in idt correct? Are irq-routines present? Is idtptr loaded in the correct way?

Gosh, I understand you: It took me several weeks to get this idt thing straight.

stay safe

[adeelmahmood1]

If you get a general protection fault and the kernel resets, your idt is either not present or the entries in the idt point to nowhere.

if we dont unmask the IRQ's and set this IDT and then
call an interrupt with
asm("int $0");
it works fine and display the appropriate message
so i think this means that IDt is present and its entries point to valid areas..
well i cant figure it out wats wrong with it

[distantvoices]

To which values did you remap the irq's?

Of course you get the isr, to which idt-entry 0x01 points, when you fire it off with "int 0x01".

but remember the remapping of pic: when you tell the pic: irq 1 = int 0x21, then it says to the cpu: int 0x21, when IRQ 1 from Keyboard comes along. And when entry 0x21 in the idt points to nowhere or is not present, you will get a triple fault.

Shall I explain it further?

[stonedzealot]

Well, I'd like to clarify what I said before...the kernel itself resets...Xsism's kernel. I compiled the thing without changing anything and it resets...

[distantvoices]

This you should talk about with xsism, i think, if you do not want to track it down by yourself. I have neither the time nor the will to search and tell you which bits'n'bytes you have to change where in xsism's code.

If you want to have someone tell you what is wrong there, try at least to track down WHERE that code blows and indicate this here.

thank you for your magnificient audience.

[slacker]

i see xsism in #osdev on mirc

gnome.wyldryde.net maybe?

[adeelmahmood1]

To which values did you remap the irq's

i m remapping them to 0x20-0x28

And when entry 0x21 in the idt points to nowhere or is not present, you will get a triple fault

ok now let me explain this to u .. what actually happening is that when i setup the IDt and then enable then interrupts with masked interrupts .. it works fine ..now after unmasking the IRQ's i get a General Protection Fault in an infinite loop..
NOTE i dont get a triple fault .. i get a GPF in a loop

so wat do u think about it
BTW thanx for ur help

[distantvoices]

I gave it a look:

Install the isr at position 0x20 in the idt, then you will get a valid interrupt handler for your timer interrupt.

Install the isr at position 0x21 in the idt, the you will get a valid interrupt handler for your keyboard interrupt.

PLS note, IRQ Lines are remapped with this kind of Remap_Pic()-Function. p. ex. IRQ 0 is mapped to int 0x20. when pic fires IRQ 0, for cpu this is the same as if you say in asm: int 0x20. the int 0x20 means amongst other things: Take the element at index 32 (hex: 0x20) of the idt and execute the code it points to.

When you unmask irq line 0 then the timer can fire his interrupt and the cpu is trapped all time in an general protection fault: IDT is present, but where the hell is the isr? This of course looks like an infinite loop, but it is just the timer interrupt.

[adeelmahmood1]

after installing the ISR's at 0x20 and 0x21 IT STILL
DIDNT WORKED

Take the element at index 32 (hex: 0x20) of
the idt and execute the code it points to.

now i have a question about this.. e.g we are adding
the ISR's in the IDT from 0 1 2 3 .... and so on
till 14 then interrupt 15 is intel reserved so we dont
define anything for this one and define another one for
int 16 ... now this isr 16 .. is it at the 15th position
(index) in the IDt or 16th....
now this is where i m confused .. for my keyboard IRQ 1
int 0x21 (mapped) should have a ISR ..
now this is 21 hex so decimal 33 .. so do i have to add
33 iSR's in my idt and then this 33rd one will be the
keyboard irq handler OR do i have to write 21 isr entries
for my IdT and then this 21 one will handle irq 1
i know this sounds confusing

When you unmask irq line 0 then the timer can
fire his interrupt and the cpu is trapped all time in
an general protection fault

but i m not unmasking the timer irq .. i m just unmasking
the keyboard irq..
now there is one interesting thing i have noted in this
that if i just load the IDT then unmask the IRQ's but
dont enable the interrupts .. just leave them disable
still i get a GPF in a loop ..

and now when i checked last time .. i added an ISR at 0x21
index in the IDT and unmask IRQ 1 .. it gets a
"WIERED VGA WRITE SIZE ERROR" bochs error and it resets
now from where thee heck this vga came in

well this IDT is a biggggg problem
ur help is really appreciated

[distantvoices]

Listen:

The idt is an array of descriptors. It can hold up to 256 descriptors.

Each descriptor points to a service routine, be it for an exception be it for an interrupt.

The first 31 Entries in this array are reserved for Intel Exceptions and faults - only 15 or 16 are actually in use. This is why we remap the PIC-IRQ's.

Starting with Entry nr. 32 (hex: 0x20) you can enter the descriptors which point to your isr's, following the above indicated premise.

What concerns the GPF: This is an exception triggered by the cpu. You can't disable exception with cli/sti. These two are related to the pic-irq's.

What concerns your sentence about unmasking timer/keyboard-IRQ: I didn't refer to your rant directly, I told an example. You have to get the trick by yourself. I won't tell you what to do where, because then you just know how to do this and that but don't see the over-all image - how things fit together.

What concerns your questions of adding isr's:

Hold on: you should have 31 Entries pointing to some exception handlers or one dummy handler, and starting with entry 32 of the IDT you can install 16 IRQ handlers - from IRQ 0 to IRQ 15 - but mark: it depends on your remapping of irq's! - and software interrupt handlers.

concerning this box-error: start debugger, config a bochserr.txt for error tracing, enter trace-on at box-cli and start that thing - surely there is something to be found?

stay safe.

[adeelmahmood1]

hi
YES i got my idt and the irq's working fine now
now the problem is that i have a small shell which takes
commands form the user as an input and then show the output
according to it .. before my kbd irq handler was working
i was using another method to make the shell work

Code: Select all

while(1){
   aprintf("\n$:>");      //user prompt
   areadCommand();
}

well now as i have the facility of keyboard iRQ i dont want to use
this while loop which is definately using alot of cpu resources..
so wat i m thinking is that whenever my kbd irq handler is called

Code: Select all

void kbd_handler(){
   areadCommand();
   outportb(0x20,0x20);
}

so now i dont have to call the areadCommand in that while loop coz
its been called in the kbd_handler

but how can i make the cpu wait at the prompt until the user presses
any key coz when the user will press the key it will enter the
readCommand function but before this i want it to wait at the prompt
and one more thing wat i can do with this timer irq.. i mean wat people
usually use it forr ??
so how can i go about this ..
thanx for ur help

[Whatever5k]

It's not the job of the keyboard driver to read a command typed in by a user. The keyboard driver just scans the code, maps it ASCII and puts it into a queue. This queue can later be read by the terminal driver which also handles READ system calls...
At the end (when your kernel will be much more bigger and powerful), you will actually have a process that will execute the shell - it's just a normal program. This program will execute READ system calls, handled by your kernel (terminal driver)

and one more thing wat i can do with this timer irq

Two major things:
1. keep track of time
2. used for scheduling processes - on every clock interrupt, we check if a process' time slice has gone - if yes, pick another one

Hope that helps...

[stonedzealot]

So, just out of curiosity, Adeelmahmood, what did you do to get rid of those GPFs in loops?