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!
#GP after #PF
Re: #GP after #PF
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- 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.
http://j-software.dk | JPasKernel - My Object Pascal kernel
- ChazZeromus
- Member
- Posts: 61
- Joined: Sun Jun 22, 2008 4:09 pm
Re: #GP after #PF
Thanks for the reply, I'm looking into that now.
The GP exception is still my main problem.
The GP exception is still my main problem.
Re: #GP after #PF
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:
Regards,
John.
Code: Select all
eip <- error code
cs <- return eip
eflags <- return cs
John.
- ChazZeromus
- Member
- Posts: 61
- Joined: Sun Jun 22, 2008 4:09 pm
Re: #GP after #PF
I thought every processor exception/fault has an error code associated with it even if it doesn't have a valid one.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:Regards,Code: Select all
eip <- error code cs <- return eip eflags <- return cs
John.
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!
- ChazZeromus
- Member
- Posts: 61
- Joined: Sun Jun 22, 2008 4:09 pm
Re: #GP after #PF
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.
You have my strongest regards John.