#GP after #PF

Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
Post Reply
User avatar
ChazZeromus
Member
Member
Posts: 61
Joined: Sun Jun 22, 2008 4:09 pm

#GP after #PF

Post by ChazZeromus »

Hi, I'm writing my very own kernel like everyone else and I am very happy to be at this wonderful forum! This is my first post and I like to ask for help in making my kernel! I want to ask more than one question here so that I don't have multiple topics so here I go:

- Problem with Page Testing
When my kernel starts up, not only paging is initialized, but it does a test page fault. It does this by writing 0x1234 to first non-present page. In page initialization the first 4 pages(pages 0 - 3) are set to present, cachability is enabled(i don't think it matters, it performs global page invalidation), global flag is set, page size is set(with PSE flag set). And a temporary page fault handler is assigned. After this is all done, I make a pointer that points to the first byte at page 4(Same as rest except for present flag) and writes the value 0x1234 to it. It generates a PF like it should. The temp PF handler simply sets the present flag in the faulted page(other fields are already valid). And in the handler, it even write to the faulted virtual address and everything work! BUT! When the handler returns and when the iret instruction is executed, for some reason it generates a GP exception! The error code said that it tried loading an invalid segment and I looked at the register dump and stack dump and saw that the iret instruction was trying to load a segment with the low word of the eip register that was saved on the stack when the PF was generated. I have practically tried all that I know and I can't seem to solve the problem. I have the timer at interrupt vector 32 working correctly and the iret works fine. So what is the problem?

- How do I detect both 8259A and 8259A-2 PIC? I know how to detect a APIC built on chip x86 arch processors but I have no clue how to detect the two PICs. I want to know how to do this so my kernel can utilized the one available if an APIC is not detected.

Thank you for reading my questions!
Image
Laksen
Member
Member
Posts: 140
Joined: Fri Nov 09, 2007 3:30 am
Location: Aalborg, Denmark

Re: #GP after #PF

Post by Laksen »

- How do I detect both 8259A and 8259A-2 PIC? I know how to detect a APIC built on chip x86 arch processors but I have no clue how to detect the two PICs. I want to know how to do this so my kernel can utilized the one available if an APIC is not detected.
A sure bet here is to parse the MADT entry in the ACPI tables. I think a flag there is if the system is PIC compatible. There you will ofcourse also find a whole load of other related information
http://j-software.dk | JPasKernel - My Object Pascal kernel
User avatar
ChazZeromus
Member
Member
Posts: 61
Joined: Sun Jun 22, 2008 4:09 pm

Re: #GP after #PF

Post by ChazZeromus »

Thanks for the reply, I'm looking into that now.

The GP exception is still my main problem.
Image
jnc100
Member
Member
Posts: 775
Joined: Mon Apr 09, 2007 12:10 pm
Location: London, UK
Contact:

Re: #GP after #PF

Post by jnc100 »

Sounds like you're messing up the stack in the page fault handler. You are aware that the page fault exception pushes an error code right? This needs to be removed from the stack (e.g. with add esp, 4) before iret. I suspect what you're doing is:

Code: Select all

eip <- error code
cs <- return eip
eflags <- return cs
Regards,
John.
User avatar
ChazZeromus
Member
Member
Posts: 61
Joined: Sun Jun 22, 2008 4:09 pm

Re: #GP after #PF

Post by ChazZeromus »

jnc100 wrote:Sounds like you're messing up the stack in the page fault handler. You are aware that the page fault exception pushes an error code right? This needs to be removed from the stack (e.g. with add esp, 4) before iret. I suspect what you're doing is:

Code: Select all

eip <- error code
cs <- return eip
eflags <- return cs
Regards,
John.
I thought every processor exception/fault has an error code associated with it even if it doesn't have a valid one.
Wow! The one thing I have not tried. Well I think i haven't tried it because I have a universal fault handler
that assumes every exception generated has the same stack structure.

Wow thank you very much! I will try it right away!
Image
User avatar
ChazZeromus
Member
Member
Posts: 61
Joined: Sun Jun 22, 2008 4:09 pm

Re: #GP after #PF

Post by ChazZeromus »

Thank you john! After some quick editing, I added a dword in the assembly module of the entry of the fault handler that determines how many bytes to destroy on the stack. I've pondered about this problem many times before but never thought I had to destroy the error code my self! All along i thought the processor does it for me when it generates a GP, but my kernel never successfully returned from a GP! Silly me! I have to read the Intel Manual more thoroughly from now on.

You have my strongest regards John.
Image
Post Reply