GPF with keyboard IRQ

[AUsername]

Hello,

The issue is that when a key is pressed a general protection fault occurs. I've been able to narrow it down to one command at the end of the keyboard IRQ "iretd" so with that I'm sorta stuck.

I know the IRQ is loaded into memory correctly.
But that's about it.

It used to execute random instructions but I somehow fixed that, now I can safely say that it will cause a GPF when a key is pressed.

Boch log:

00001800426i[BIOS ] bios_table_cur_addr: 0x000fb994
00008023335i[BIOS ] Booting from 0000:7c00
00018720612e[CPU0 ] fetch_raw_descriptor: GDT: index (6f)d > limit (17)
00037752000p[WGUI ] >>PANIC<< Window closed, exiting!
00037752000i[CPU0 ] CPU is in protected mode (active)
00037752000i[CPU0 ] CS.d_b = 32 bit
00037752000i[CPU0 ] SS.d_b = 32 bit
00037752000i[CPU0 ] | EAX=00000001 EBX=00000000 ECX=00000000 EDX=000003d5
00037752000i[CPU0 ] | ESP=0008ff90 EBP=0008ffb0 ESI=00004012 EDI=00000000
00037752000i[CPU0 ] | IOPL=0 id vip vif ac vm rf nt of df if tf sf zf AF PF cf
00037752000i[CPU0 ] | SEG selector base limit G D
00037752000i[CPU0 ] | SEG sltr(index|ti|rpl) base limit G D
00037752000i[CPU0 ] | CS:0008( 0001| 0| 0) 00000000 000fffff 1 1
00037752000i[CPU0 ] | DS:0010( 0002| 0| 0) 00000000 000fffff 1 1
00037752000i[CPU0 ] | SS:0010( 0002| 0| 0) 00000000 000fffff 1 1
00037752000i[CPU0 ] | ES:0010( 0002| 0| 0) 00000000 000fffff 1 1
00037752000i[CPU0 ] | FS:0010( 0002| 0| 0) 00000000 000fffff 1 1
00037752000i[CPU0 ] | GS:0010( 0002| 0| 0) 00000000 000fffff 1 1
00037752000i[CPU0 ] | EIP=c0000bc0 (c0000bc0)
00037752000i[CPU0 ] | CR0=0xe0000011 CR1=0 CR2=0x00000000
00037752000i[CPU0 ] | CR3=0x0009c000 CR4=0x00000000

(If the actual IRQ would be useful I'll post that, I don't want to make this post any longer than needed )

Obviously I'm new to this, so does anyone have any ideas what's going on?

Thanks. ^-^

[CodeCat]

Did you program the PIC to remap the IRQs to different interrupt numbers? If you don't, you'll get an interrupt that coincides with a CPU exception interrupt, and the handler for that may erroneously assume that an error code of some sort has been pushed on the stack.

[AUsername]

Yes, and the keyboard IRQ is mapped to interrupt 33.

[gzaloprgm]

Are you in ring3? In that case, you'll need to or your idt flags to 0x60, so irq can fire and be handled correctly if you were in ring3, and remember a correct tss!

Otherwise it may be a problem within your isr code.

Cheers,
Gonzalo

[AUsername]

The keyboard driver is in ring 0(although it should be in ring 1).
I'm pretty sure it's a stack issue at this point.

[Combuster]

I've been able to narrow it down to one command at the end of the keyboard IRQ "iretd" so with that I'm sorta stuck.

Pretty much guaranteed a stack issue.

Start bochs debugger, set a breakpoint at the IRET in question, then do a stackdump to see what it is trying to return to. Checking your ISR for unmatched push/pop instructions and unsaved registers can probably find you the error as well.

[Dex]

Have you tryed replacing your keyboard IRQ function with one that does nothing, just to see if it still crash ?.
Also you are sending end of IRQ ?
Also check you are not using sti or cli in your IRQ function.

[AUsername]

Sorry for randomly disappearing, was busy.

Pretty much guaranteed a stack issue.

Start bochs debugger, set a breakpoint at the IRET in question, then do a stackdump to see what it is trying to return to. Checking your ISR for unmatched push/pop instructions and unsaved registers can probably find you the error as well.

I've checked the ISR several times it all looks ok.
I do know that the stacks are corrupting though.

Have you tryed replacing your keyboard IRQ function with one that does nothing, just to see if it still crash ?.
Also you are sending end of IRQ ?
Also check you are not using sti or cli in your IRQ function.

"Have you tryed replacing your keyboard IRQ function with one that does nothing, just to see if it still crash ?." - Yes

"Also you are sending end of IRQ ?" - Yes

"Also check you are not using sti or cli in your IRQ function." - Yep

It's an issue with the stacks, I tried to call the interrupt and it crashed with a general protection fault(_asm int 33).

So what would cause corruption of stacks?
(I'll get the actual stack info in a bit having issues with boch debugger)

[gzaloprgm]

Having your ISR code will help, probably you're pushing one extra reg or forgeting to pop one.

By the way, have you tried replacing the whole interrupt service routine with some like JamesM's or Bkerndev's?

Cheers,
Gonzalo

[Combuster]

It's an issue with the stacks, I tried to call the interrupt and it crashed with a general protection fault(_asm int 33).

That sounds more like a borked IDT...

Come on, get the bochs debugger, single step through it and actually show us some dumps (stackdumps, IDT dumps, GDT dumps, the exact instructions that cause the crash)

[AUsername]

http://pastebin.com/m398edbcf

I hope that's what you wanted. I typed c after the breakpoint because the next instruction is _asm int 33. I was single stepping for a bit. It was looping for awhile so I just went that route.

If you need the single step I'll go ahead and do that anyway.

[neon]

It's an issue with the stacks, I tried to call the interrupt and it crashed with a general protection fault(_asm int 33).

That sounds more like a borked IDT...

I had him put a CLI+HLT at the beginning of the interrupt handler and insure it was installed in the IDT. He called the interrupt via _asm int 33 and it got into the interrupt handler fine which makes me believe the IDT is fine and IRQ properly installed.

[Combuster]

The problem is his debugging skills.

<bochs:5> c --- executes 0xc000141d(_asm int 33)

Wrong - executes the int AND the many instructions following it.

There's no point in good debugging if you can't tell us where it goes wrong and only the consequence.

That's why you have to SINGLE STEP to see WHAT EXACTLY is causing the exception. Then when you found the point, you can check there to see what matches your expectations, and what not.

[AUsername]

http://pastebin.com/d19d94e7f

There ya go.
Hope that's what you meant. ^-^

Update:

The stack issues appear to be fixed now.
I changed where the stack was loaded into memory, made the IRQ naked, and made the variables static. I also removed "add esp, 12" and it worked it just fine.

Now it works when it feels like it. Sometimes you press a key and the character prints. Sometimes a gpf occurs.

Boch log:

00015786599e[CPU0 ] fetch_raw_descriptor: LDTR.valid=0
00015898002i[CPU0 ] LOCK prefix unallowed (op1=0x53, attr=0x0, mod=0x0, nnn=0)
00015898003i[CPU0 ] LOCK prefix unallowed (op1=0x53, attr=0x0, mod=0x0, nnn=0)
00015898004i[CPU0 ] LOCK prefix unallowed (op1=0x53, attr=0x0, mod=0x0, nnn=0)
00015898005i[CPU0 ] LOCK prefix unallowed (op1=0x53, attr=0x0, mod=0x0, nnn=0)
00015898006i[CPU0 ] LOCK prefix unallowed (op1=0x53, attr=0x0, mod=0x0, nnn=0)

Btw, I'm using VC++.

[Steve the Pirate]

I had a problem where my keyboard ISR would run, and then immediately after I would get a GPF. What fixed it for me was turning down the compiler optimisation level.