(i686/i386) Random Faults that didnt happen before after loading IDT

[tunge]

So recently i added an IDT (from the interrupt tutorial) to my kernel (https://github.com/therealtunge/tungeos) and for some reason I'm getting a lot of fault int's (int 0x8, 0x9, 0xD) at random points in my code that didn't triple fault (it would if there was no IDT) before.
What am I doing wrong?

[JackScott]

I had a quick look at your GitHub repo, but I couldn't find any IDT code at all.

Are you able to make sure your GitHub repo contains the exact same code that you're having trouble with? And ideally, also provide a commit (or commits) that shows the code that changes between "working" and "not working".

[tunge]

oh yeah sorry git tried to upload a 1GB log file, the commit should be there now:
broken (idt added): https://github.com/therealtunge/tungeos ... 5b091e047d
working (no idt): https://github.com/therealtunge/tungeos ... ab207abc3f

[JackScott]

There's a lot of code in that commit, including changes to both your boot page directory and the start of userspace code. Are you absolutely sure it's your interrupt code that's the problem and not faulty code elsewhere?

[tunge]

im SURE, it worked perfectly before (the userspace changes are irrelevant) the idt is in /kernel

[iansjack]

Have you reprogrammed the PIC?

[tunge]

ok so i reprogrammed the pic (aka stole code from the pic wiki page)
if i set both offsets to zero i get int 6 (?)
if i set it to 0x20 and 0x28 i get int 13 (which should've triple faulted before i added the idt)

[iansjack]

There’s a host of possible causes of a GPF, so now you need to determine the address of the faulting instruction. You can either get this from the qemu log or by debugging with gdb.

This would be a very good opportunity to learn to debug with gdb.

However, I’m not very impressed with your Frankenstein method of cut and pasting random code that you don’t understand. I’d recommend that you slow down and make sure that you properly understand each step before progressing further.

[tunge]

the error code the gpf gives me is garbage data
yes i know how to use gdb (ive tried it, its borked).
yes i know what the code does

[iansjack]

The error code will not be garbage (but your reading/interpretation of it may well be).

Gdb is a very useful tool which is not borked.

If you know what the code does, why did you set the offsets to zero?

I don’t think that I can be of assistance to you.

[tunge]

i accidentally set the offsets to zero (forgot to make a prototype)
also the error code is 1138 which sets reserved bits

[Octocontrabass]

also the error code is 1138 which sets reserved bits

If this is an error code for #GP, there are no reserved bits set. Are you trying to interpret it as if it were an error code for #PF?

[iansjack]

It does indicate a rather unlikely selector value, but it’s a legitimate error code. Or, of course, the OP may be reading the wrong value for the error code.