IRQ stop after multi-tasking

[GLneo]

hi all, ok, i was just wondering if any one has had this problem, my kernel only gets 1 irq then no more???, the first thing i do at a switch is EOI, and i know it doesn't have to do with the task becouse task1 a is running before the first IRQ, just wondering if any one has had this problem ,thx

[durand]

There could be a few reasons why this is happening. What about...

1. When you return from yuor IRQ handler, are interrupts re-enabled again?

2. Are you returning to the correct process? (task1)

3. Does the EOI code work?

Perhaps you've fixed this problem already?

If not, you need to give more information about how you're doing things. Like are you using an interrupt gate, task gate, trap, etc..

Durand.

[Candy]

hi all, ok, i was just wondering if any one has had this problem, my kernel only gets 1 irq then no more???, the first thing i do at a switch is EOI, and i know it doesn't have to do with the task becouse task1 a is running before the first IRQ, just wondering if any one has had this problem ,thx

I must admit that the search function isn't always as helpful as it could be, but there have been so many threads on people only receiving one interrupt that I don't really see your question validity.

Did you try to search before posting?

[GLneo]

@Candy: yes, i typed stuff like intruppt and multi-tasking stop nothing came back but junk

@durand: i'm just using an interrupt because i'm running all code in the kernel at ring0

[durand]

K, well, what kind of interrupt? interrupt gate, trap gate, task gate.

So, from ring 0 to ring 0 and back again? If I recall correctly, the IF flag doesn't get re-enabled if you iret back from ring 0 to ring 0. (or something like that). but i'm not sure You should get your hands on the intel development manuals and examine the behaviour of the IF flag when you return through your particular interrupt mechanism.

http://www.intel.com/design/Pentium4/do ... tm#manuals

[JoeKayzA]

AFAIK, since the interrupt flag is part of eflags, it should get popped from the stack when you leave the interrupt service routine (with 'iret'). So when interrupts were enabled before you entered the isr, they should be re-enabled when you leave it.

However, when you do a task switch inside the ISR (e.g. you push the state and then swap the stack), are you sure that the new stack, from which you pop the state, also has the interrupt flag set? You should check this out.

cheers Joe

[durand]

Okay, I checked. The IF flag is only restored if the CPL is less than or equal to the IOPL. And the IOPL is restored only if the CPL is 0. So, perhaps your problem also lies in the IOPL values?

You are doing an iret and not a ret? If your previous task keeps working, and you haven't complained otherwise, then your stack is probably correct .

It could just be privilege levels and the like... only you will know.

[GLneo]

well, i can still manualy do it: asm("int 33"); and it swicthes fine but i can only use the keboard 1 time before a fail, so i dont think my tasking code is wrong, but is this correct for eflags:

Code: Select all

stack->eflags = 0x00000202;

[GLneo]

I know my IRQ is lower so right at the start i do a outport(0x20, 0x20);, but thx

[OZ]

sorry, I didn't see that you had already written that in your first post. Never mind if my next proposal is even dumber ... ;D
But is it possible that your handler itself gets interrupted ?

[GLneo]

that could be happening, because i EOI at the start

p.s. how do you do outport in asm i've tryed:

Code: Select all

mov bl, 0x20
    out bl, bl

[Candy]

that could be happening, because i EOI at the start

p.s. how do you do outport in asm i've tryed:

Code: Select all

mov bl, 0x20
    out bl, bl

You can only use out with dx and al/ax/eax.

Code: Select all

out dx, al

Intel sends their regards

[GLneo]

i hate asm
what does

Code: Select all

00003473225e[CPU  ] load_seg_reg: GDT: FS: index(0b77) > limit(000017)

mean???

[Brendan]

Hi,

Code: Select all

00003473225e[CPU  ] load_seg_reg: GDT: FS: index(0b77) > limit(000017)

Bochs tried loading FS with a descriptor that is past the limit of the GDT.

Either your GDT limit is wrong, you're loading the wrong descriptor into FS, or the CPU jumped into the middle of nowhere and started executing the wrong thing. IMHO the last possibility is most likely...


Cheers,

Brendan

[Pype.Clicker]

this is the kind of things you're very likely to encounter when your ISR are messing up the stack. You e.g. pushed fs then eax and you then pop fs without removing "eax" value first, which results in garbage being loaded in the segment register.