OSDev.org

Octocontrabass wrote:Inline assembly to mess with rflags should be okay since your kernel is compiled with -mno-red-zone as long as you do it carefully. Since you haven't remapped the PICs, the only IRQ that could reach your page fault handler without causing a page fault is IRQ6 from the floppy drive, and I suspect you're not using one of those.

        __asm__ __volatile__ ("pushfq ; popq %0 ; cli" : "=r"(rflags) : : );
and later:
        if (rflags & 0x200) {
                __asm__ __volatile__ ("sti");
        }

I guess that leaves some fault in the page fault handler itself that causes it to report nonsense instead of the actual error?

        movabsq $err_msg_page_fault, %rdi
        movq    (%rsp), %rsi
        movq    8(%rsp), %rdx
        movq    %cr2, %rcx
        xorq    %rax, %rax
        call    kprintf
        hlt

nexos wrote:If you are using GRUB to boot, this may be the problem:

The ACPI RSDP is located at 0xf58d0, which is within the range (0xf0000-0xfffff) marked reserved.

Gigasoft wrote:Why does your page fault message contain an extra 0 at the end? Besides, the lower 32 bits of the address looks like a typical value for the Eflags register when in Virtual 8086 mode, if you ignore the extra 0.

zaval wrote:

The ACPI RSDP is located at 0xf58d0, which is within the range (0xf0000-0xfffff) marked reserved.

this is a correct range for IA-PC RSDP location and it's "read only BIOS". it cannot be ACPI reclaimable memory, but wether should it be reserved is the question too. interestingly, your loader reads it after mapping? what if you tried doing this before, on a physiscal machines?

nexos wrote:At what point does it page fault? When you add the PTE, or when use flush it to the TLB?

MichaelPetch wrote:As for your page table related problems are you assuming the memory with your PTs, PD, PDP, PML4 etc contains all zeroed in it already? Possibly on real hardware memory isn't zeroed out. Another source of problems could be if you assume memory is zero and you haven't correctly zeroed out the BSS area that may be used by the _C/C++_ code (variables expected to be initialized to zero that have non zero values could cause bizarre behaviour in your code). That could cause weird and wonderful issues. I see a lot of custom bootloaders that read kernels and forget that step. Don't ever assume the memory you may be using is zero. Maybe that isn't your problem but I am warning you just in case.

Hopefully you aren't using the area that the EBDA sits in just below 0xA0000. That should be considered reserved as well and you shouldn't put your own code or data there.

sj95126 wrote:I would load the kernel a little lower but there's a most obnoxious Bochs bug that was causing me problems if I did that.

Octocontrabass wrote:

sj95126 wrote:I would load the kernel a little lower but there's a most obnoxious Bochs bug that was causing me problems if I did that.

Is it the bug where INT 0x13 can't load data across a 64k boundary? If so, that's a feature: some real hardware won't cross 64k boundaries either.

sj95126 wrote:It's not that one, but it's similar. It's a weird combination of factors, but basically a multi-sector LBA read to xxxx:0000, where xxxx is just below 1000h, will throw errors when you reach segment 1000h. This doesn't happen with any other value, like, say, segment 2000h.