Page 1 of 1
loop errors (GPF)
Posted: Tue Jun 10, 2008 3:02 pm
by suthers
Ok so I've just started designing my PIC, so I want to write a keyboard driver...
But If the CPU is halted and IF = 0 at the end of my OS, I can't test the driver, so I decided to add a simple loop, So i tried:
Code: Select all
volatile int test = 10;
...
while(test != 0){};
This produced in asm:
Code: Select all
000004A8 8B442408 mov eax,[esp+0x8]
000004AC 85C0 test eax,eax
000004AE 75F8 jnz 0x4a8
But a GPF occurs.
When I trace it, it says that the GPF is cause by the test line, I don't understand how this is possible, any clues?
Thanks in advance,
Jules
Posted: Tue Jun 10, 2008 3:08 pm
by Combuster
a GPF can also occur because of an misfiring interrupt. Have a look at the error code to see where that happens exactly.
Posted: Tue Jun 10, 2008 3:09 pm
by Korona
It's _not_ possible. The GPF is most definitely caused by an interrupt. A halt instruction cannot cause GPFs. (At least not when it does not reference memory, see intel manuals)
Posted: Tue Jun 10, 2008 4:37 pm
by suthers
Sorry, my fault, I just realized that the return value (EIP) pushed onto the stack during an interrupt for a GPF is the address of the instruction before the instruction that caused the fault, so its the conditional call that caused the GPF.... (sorry, stupid mistake..., thanks again to AJ for showing me sandpile.org)
I've tried different types of looping which generate different types of code such as a jmp that jmps onto its self, etc... all of them have a GPF caused by the various forms of jmp instructions used...., so I don't think it's an interrupt, that would be to much of a coincidence....
Any clues?
Thanks in advance,
Jules
Posted: Wed Jun 11, 2008 7:30 am
by AJ
Korona wrote:It's _not_ possible. The GPF is most definitely caused by an interrupt. A halt instruction cannot cause GPFs.
Just to clear this up (I may be missing something but I don't see how this is relevant to the original question), a halt instruction
can cause a GPF if you are in ring 3.
Cheers,
Adam
Posted: Wed Jun 11, 2008 8:55 am
by Korona
AJ wrote:Korona wrote:It's _not_ possible. The GPF is most definitely caused by an interrupt. A halt instruction cannot cause GPFs.
Just to clear this up (I may be missing something but I don't see how this is relevant to the original question), a halt instruction
can cause a GPF if you are in ring 3.
Yes, sorry, I was talking about the test instruction ^^;;.
Posted: Wed Jun 11, 2008 9:02 am
by Combuster
Well, the only two reasons for an exception in this code is because ESP+xx is out of range, or the code is. With flat address spaces, neither should be a problem.
Will you please post the error code pushed as part of the GPF (and for completeness' sake, the other registers)
Posted: Wed Jun 11, 2008 10:18 am
by suthers
After a fewer hours of analysing stack output, I finally reallised why I had put 'add esp, 4'
So the error code popped onto the stack by the CPU when the GPF occurs is: 0x103
Thanks in advance,
Jules
P.S. I would have looked them up in the intel manuals, but I'm at school, when I try to load them, the terminal I'm on crashes so...., yah I should have them saved on my laptop, but the only one I have saved says under exceptions GP, it says lookup chapter five which in their infinite kindness is in another manual....(which I haven't downloaded...)
Posted: Wed Jun 11, 2008 12:11 pm
by Combuster
its an external interrupt (bit 0), the entry number is 0x20. I don't know the other bits by hard, but it probably claims IDT entry #20 is borked. (try "info idt 32" in bochs)
Which makes completely sense
Posted: Wed Jun 11, 2008 1:08 pm
by suthers
when i do info idt 32, it just gives me the base and the limit.
Which I don't think is very useful, but just incase:
Code: Select all
Interrupt Descriptor Table (base=0x00000000001004ee, limit=255):
Thanks in advance,
Jules
Posted: Wed Jun 11, 2008 1:23 pm
by suthers
Oh I get it, It means give the info on the interrupt you pass to it (32)...
Sorry I'm really stupid sometimes....
Thanks, Combuster, thanks to you I'm fixing bugs and learning how to use bochs debugger...
And i don't have an 0x20 idt entry...
(Weird that it gives a value for it, i've gone through my kernel, that comes out somewhere in the middle of a string...)
But it is where I remapped my PIC (So that would be system timer...)
So I removed the PIC remap.
But I now get a divide by zero error (weird....) That comes from the same instruction....
Jules
Posted: Wed Jun 11, 2008 2:51 pm
by Combuster
base=0x00000000001004ee
Yuck, unaligned table
So I removed the PIC remap.
Not remapping the PIC is considered a Bad Thing(tm). Now when you get interrupts it will look like you get exceptions instead of hardware interrupts, as they use the same vectors.
You'd better fill up the IDT entries with
proper values to end up with a usable system.
Re: loop errors (GPF)
Posted: Mon Jun 23, 2008 3:19 pm
by suthers
Thanks, fixed, I filled the IDT with proper values, that fixed it, for some reason the timer interrupt fires once at the beginning of the loop...
Thanks to all,
Jules