Activating paging corrupts stack

[computafreak]

Or to be precise, leaving the method which activates paging does. I get a page fault with the following details:
Wrote to memory address 0xA0000010
Occurred in ring 0
CR0: 0x80000011 (0xE0000011 in Bochs, not sure if VPC handles registers differently)
CR3: 0x10C000
I think it's something to do with memory allocation; I'm using the code from JamesM's tutorials for paging (specifically, part 6). My IDT and GDT are completely set up, and I'm using identity mapping, so virtual addresses are equal to physical addresses. One thing that has been the same while I've been trying to fix the problem, is that I have always allocated exactly 0x5000 bytes of memory

For some reason, if I explicitly set up a stack with size 0x4000, the memory address changes to 0x67F00000, and I get exception 6 in Bochs. I don't really understand why this happens - could someone enlighten me please?

If anyone needs the Bochs logs, I'll upload them

[jal]

Or to be precise, leaving the method which activates paging does. I get a page fault with the following details:

What happens if you don't actually activate paging, but leave the function intact otherwise? If this works, it's propable the identity mapping didn't work out quite as well as expected. If it still crashes, it has nothing to do with the paging. Use Bochs debugging (especially the new graphical debugger) and see where it goes awry.


JAL

[yemista]

In bochs, try page 0xADDRESS. This command will give you the physical translation for virtual ADDRESS so you can see if you setup paging correctly. Where does ss point? If you put 0x4000 in esp, I can see how you would get a page fault if you did not map those address but instead only mapped the kernel.

[computafreak]

Thanks for the replies. If I don't activate paging (comment out anything which writes to CR*) I get another invalid opcode exception. Bochs says that there is no linear address available for paged memory 0xA0000010. However, I'm still slightly concerned about the odd value of CR2 in Bochs, I don't think that has anything to do with it, but it's one more thing to muddy the waters. At one point I was suspicious of JamesM's memory allocation code, since that could conceivably mess up the page tables and directories enough to cause a page fault (perhaps overwriting the stack?)

[yemista]

I had some trouble with James Molloys code too, but it was because I didnt implement it right. Something is screwed up somewhere. Install a page fault handler that just loops forever so you can check CR2 when the fault happens. If 0xA0000010 is its value, and your kernel is no where near that address, then something somewhere is trying to reference it or you would not be getting that error. It could be a linking error, bad pointer, assembly functions not accessing c parameters correctly, descriptor tables not setup right so memory references are not what you think they are, or a whole lot of other things. The one thing you know for sure though is that something somewhere is referencing 0xA0000010, and that is not a valid virtual address.

[jal]

Thanks for the replies. If I don't activate paging (comment out anything which writes to CR*) I get another invalid opcode exception. Bochs says that there is no linear address available for paged memory 0xA0000010.

You do not activate paging, but Bochs gives a paging fault? I smell something fishy...


JAL

[computafreak]

My apologies. I made a stupid typo in my message. When my page fault occurs, CR0 is 0xE0000011 (should the E be 8?), CR1 I never get - its reserved, CR2 is 0xA0000010, CR3 is always 0x10C000, CR4 is 0 and SS is 0x10. Just to clarify, Bochs says that 0xA0000010 does not correspond to a linear address when I enter "page 0xA0000010". It is not stated in the kernel itself. I don't get a paging fault before I activate paging

[jal]

My apologies. I made a stupid typo in my message.

Still, it seems you haven't followed up on advise to actually debug what's going on using the Bochs debugger, right?


JAL

[yemista]

My apologies. I made a stupid typo in my message. When my page fault occurs, CR0 is 0xE0000011 (should the E be 8?), CR1 I never get - its reserved, CR2 is 0xA0000010, CR3 is always 0x10C000, CR4 is 0 and SS is 0x10. Just to clarify, Bochs says that 0xA0000010 does not correspond to a linear address when I enter "page 0xA0000010". It is not stated in the kernel itself. I don't get a paging fault before I activate paging

Of course you are not going to get a paging fault if paging is not activated. You get it once you activate because your paging is not working right. Whatever is in CR2 is the address that caused the page fault, which means somewhere, some peice of code, reference that address, or you did not setup the tables right. 0xA0000010 does not correspond to a linear address means there is no page setup with which to translate that address.

[Combuster]

Which also suggests that with paging disabled, you are accessing addresses that do not exist. (0xA0000000 isn't a normal address to be working at)

[computafreak]

Sorry for the delay. I've been getting the graphical debugger working - it's much easier to use than the command line! Something I've just noticed is that if I write a string to the console after I switch the page directory, enable paging and enable interrupts, but before I leave the method, I get no problem at all in either VPC or Bochs. On the other hand, if I don't write anything, I get the invalid opcode exception in Bochs, and the page fault in VPC. By my guess, it means that I'm allocating memory for the paging structures where I shouldn't be, and then zeroing it out; the stack happens to be there, so I can't drop down to Main(). Would this be about right?

[yemista]

You really have to step through it and find the place where it doesnt work as you expected it to. I understand you probably believe it has something to do with the page tables, but you must also understand there are a lot of things that could give the same symptoms. When you first load your kernel, you should be able to access all the memory before you enable paging. put your stack at 0xf0000000 if you want to be safe and make sure that the page tables are no where near that address.

[computafreak]

Thanks for the advice. I've stepped through, and the page fault occurs when I leave the InitialisePaging routine (oddly enough, not the method which actually writes the value to CR0, perhaps because the stack grows downwards?). The only other thing which I noticed is that the value of CR0 before paging was activated was 0x60000011; this would be what caused the odd value of CR0 when I OR in order to enable the paging bit, I think

[Combuster]

the page fault occurs when I leave the InitialisePaging routine

That suggests that ESP and EBP are pointing where they should not, or you haven't mapped in the stack correctly...

the value of CR0 before paging was activated was 0x60000011;

That's bochs for you

[computafreak]

That suggests that ESP and EBP are pointing where they should not, or you haven't mapped in the stack correctly...

Which is odd - I get an identical error whether I map all of memory or the first 16 MB. Surely this shouldn't be happening when I'm using identity mapping?

Would it help if I posted my linker script? That's the only place where I use such high memory addresses.
Incidentally, when I explicitly set up my stack the CR2 register upon a page fault becomes 0x67F00000. However, the amount of memory allocated remains at 0x5000 bytes