First 2MB, can't unpage even a little [RESOLVED].

[stonedzealot]

This is how I'm going about the change of base thingamajig. I decided to go with the "start paging early" method. Therefore, my current code looks like this:

[Link the kernel to 0xC00100000]
[Bootloader loads kernel to 1MB, no GDT magic]
[In the assembly stub]
first 4MB mapped to 0x0 and 0xC0000000
paging enabled
jump from 0x1000xx to 0xC0000000 + 0x1000xx
add 0xC0000000 to ESP
jump to kernel, continue as usual.

This works, I'm happy to say. The only thing is that I don't want that top 4MB to be mapped two places forever, and I don't want all 4MB mapped. So the first step I took was to scale down the amount that I mapped. I got it to run without 2-4MB mapped, just fine... but then if I try and unmap even the first 4k of memory from 0x0, the kernel detonates (gives a page fault) as soon as interrupts are enabled.

This question essentially boils down to: what exactly do I need paged in that top 4MB that would cause the kernel to page fault if it wasn't available? My kernel is still paged, my kernel's stack page is all right, VGA memory is cool..., everything else should be untouched anyway, so why the page fault?

[proxy]

i am doing the same thing and completely unmap the first 4 megs after i do the jump.

One thing you have to realize is that lots of memory references you will need to add 0xc0000000 too, such as the 0xb8000 for video and any addresses you get from grub too.

also if you do any PNPBios or Bios32 scans you will need to add that much to all address you look at too.

proxy

[stonedzealot]

Well, in this case, everything that is mapped at 0x0 is mapped at 0xC0000000 *always*. I've already accounted for the stack page, the VGA and I don't get anything from pnpbios, bios32 or grub (I use my own loader). I just don't understand why it would generate a page fault, considering nothing uses the memory that I'm unmapping (that's why I'm unmapping it).

[proxy]

like i said, i am doing the same exact thing (but did not run into thsi problem).

i suggest you double check all your code and also make a much more verbose exception handler (one that prints out all registers and such) this way you will know the eip and esp (at a minimum) that touched the low pages. From this you can compare to an asm dump and find out _exactly_ where you are going low.

proxy

[stonedzealot]

I've got a pretty nice exception handler...

Ouput:
Interrupt: 0xE
Error Code: 0x2
EAX: 0
EBX:0xD00004FC
ECX:0x482
EDX:0xD00000BC
DS->GS:0x10
EDI: 0x1
ESI: 0x7C06
EBP: 0xC000FFB8
ESP: 0xC000FF58
CS: 0x8
EIP: 0xC01002BF
Flags: b10000000010000110

I know the eip and cs, but I can't easily translate that into an instruction...

[stonedzealot]

Wait, of course I can... I just remembered ndisasm =)

[stonedzealot]

I've managed to track down the address 2BF in the kernel.bin image, and it's the command 89 20, which is "mov esp, [eax]" but the confusing part is that it's in the function "timerhandler" which never gets called in the running of the kernel... if I get rid of that line, it moves to another line within the interrupt handler (can't really see how, but it seems to be connected to outportb(0x20,0x20)). If I get rid of that, we're ok.

The real thing that's confusing is that the timer handler shouldn't ever be firing because the IRQ is masked and the PIT isn't initialized...

EDIT:
I figured out that the page faults are coming from the manipulation of the kernelprocess and currentprocess pointers that point to NULL 0... but this doesn't explain why in the hell the Timer handler is firing....

[stonedzealot]

So this really turned out to be a ***** of a problem. I could'nt unpage the first 4k because 0x0 is null and I had currentprocess and kernelprocess pointing to null, the only reason these were being used however was that I had a bug in my PIC code that made it work, except when you plug in 16 (mask all)... cascading failure, I suppose. Amazing the things that happen.