[RESOLVED] Need help with paging problems

[chibicitiberiu]

I have a problem with the kernel... I set up paging in the bootloader to map the kernel to 3gb, and identity map the first 4 mb. Then I jump to the kernel.

I do the same in the kernel, so it has it's own page directory, to be easily set up... but when I try to switch to the new page directory I get a triple fault. What could be the problem?

I posted my virtual and physical memory manager, the kernel entry (the C part) and the parts related to paging in the bootloader. I also attached the linker script, maybe it helps...
Here are the links [they will expire in 1 month]:

[links removed]
memory/mmngr.asm
memory/mmngr_vi.c
memory/mmngr_ph.c
memory/lib/pde.c + pte.c
main.c

bootloader/stage2.asm + paging.inc
linker_script.ld

I tried setting up the kernel at 0x100000 instead of 0xC0000000, but I get other errors, like page fault, or coprocessor fault... I have no idea what the problem could be. I've been trying to find a solution for about two weeks already... i can't seem to find any...

Thanks in advance,

Chibici Tiberiu
Currently developing CTA Operating System.

[gerryg400]

. but when I try to switch to the new page directory I get a triple fault. What could be the problem?

Which file, which line crashes ?

[Brynet-Inc]

It's a game we're supposed to play, find the bug and fix it.. for free!

[chibicitiberiu]

. but when I try to switch to the new page directory I get a triple fault. What could be the problem?

Which file, which line crashes ?

It's the highlighted line in mmngr_vi.c (line 170)... sorry that I forgot to mention

And I've been trying to find the problem for 2 weeks and I just can't seem to find any way to fix it.
Why does it triple fault when changing the page directory, when changing register cr3? The possible problems I see is either the physical memory manager doesn't work properly, or there is a bug I haven't found yet.
About the physical memory manager, I tried a dozen of things... like only initializing memory above 0x100000 + kernel size... I just can't find the problem.

I'm thinking of not enabling paging in the bootloader, but then how do I make the kernel execute code, and all variables to start at 0xC0000000? and don't tell me about the gdt trick, i won't listen.

[chibicitiberiu]

It's a game we're supposed to play, find the bug and fix it.. for free!

Maybe you are right... but i'm not so experienced and I need help. This forum is like the last forum I want to post to, because I see that most of you are selfish and don't want to help, just to show off what amazing OS you created, and how smart you are, and how stupid is everybody else.
But who am I to judge...?

Maybe I didn't have such a great day...or month, nothing seems to work right for me... and because of that i'm a pessimist...but who cares...

[Brendan]

Hi,

Why does it triple fault when changing the page directory, when changing register cr3?

If it crashes when doing the "mov cr3" instruction, then there's only 2 possible causes (that I can think of) - either you're not running at CPL=0 (and any attempt to modify any control register causes a general protection fault); or the physical address of the page at EIP isn't the same in the new virtual address space (you change CR3, the instruction after the "mov cr3" vanishes, you crash).

I'd assume the last problem is a lot more likely. To check, use something like Bochs debugger and stop the emulator just before the "mov cr3" is executed (e.g. with a breakpoint). Then check what you're about to load into CR3 ("r" to see the contents of general registers) and examine the new page directory, page table, etc (e.g. "xp" to examine physical memory) to confirm that the physical page at EIP in the new virtual address space is the same as the physical page in the previous virtual address space (or at least contains the same data).

If that's not the problem, then at a minimum you'll have a nice log from Bochs saying which exception was caused at which virtual address, etc...


Cheers,

Brendan

[chibicitiberiu]

Hi,

Why does it triple fault when changing the page directory, when changing register cr3?

If it crashes when doing the "mov cr3" instruction, then there's only 2 possible causes (that I can think of) - either you're not running at CPL=0 (and any attempt to modify any control register causes a general protection fault); or the physical address of the page at EIP isn't the same in the new virtual address space (you change CR3, the instruction after the "mov cr3" vanishes, you crash).

I'd assume the last problem is a lot more likely. To check, use something like Bochs debugger and stop the emulator just before the "mov cr3" is executed (e.g. with a breakpoint). Then check what you're about to load into CR3 ("r" to see the contents of general registers) and examine the new page directory, page table, etc (e.g. "xp" to examine physical memory) to confirm that the physical page at EIP in the new virtual address space is the same as the physical page in the previous virtual address space (or at least contains the same data).

If that's not the problem, then at a minimum you'll have a nice log from Bochs saying which exception was caused at which virtual address, etc...


Cheers,

Brendan

The first option is very unlikely because i have managed that irq, and it should display a screen of death. I'm going to try Bochs, although i'm kind of unfamiliar with using this tool.

Thanks for reply anyway . I have a question, how can I know the address of a specific instruction, because in Bochs breakpoints are based on addresses, right? I don't think I want to go through each and every instruction until I find it (I tried this before... didn't find it, and I only wasted time with Bochs, and did not find the problem).

[Brendan]

Hi,

I have a question, how can I know the address of a specific instruction, because in Bochs breakpoints are based on addresses, right? I don't think I want to go through each and every instruction until I find it (I tried this before... didn't find it, and I only wasted time with Bochs, and did not find the problem).

For newer versions of Bochs you can insert a magic breakpoint instruction ("xchg bx,bx") in the code, and Bochs debugger will stop when it executes this instruction. This instruction is harmless and has no effect on normal CPUs or when Bochs is running without the debugger enabled.

For old versions of Bochs you can do something like:

Code: Select all

    push ecx
    mov ecx,0
.stop:
    jecxz .stop
    pop ecx

This will lock up the computer. When the computer has locked up, you can break into the debugger (control+c) then change ECX with the debugger ("set ecx=1") and then single-step from there.

The other alternative is to use a tool like "objdump" to find out where you want a breakpoint, then set a breakpoint in Bochs before executing any code. This is probably the hardest way (especially if you're using a high level language, where the source code looks nothing like a disassembly).


Cheers,

Brendan

[chibicitiberiu]

FINALLY found the bug. It was mapping 0x0 to 0xC0000000 instead of 0x100000. Fixed it and now the kernel works.