[RESOLVED]Bitmap Page Frame Allocator - Bit toggle problems?
Posted: Thu Jan 13, 2011 5:38 pm
I am writing a 32-bit x86 operating system for the learning experience.
About 5 days ago I got paging to work, and I assumed my physical memory manager was manageable because of it.
However, now I am working on heap creation and allocation functions, and have exposed what I believe to be a bug
in my physical memory management.
I use a bitmap-based allocator, for its space and simplicity. The bug is like this:
Basically, the last 12 bits in a bitmap for most of lower memory up to about where
VGA memory is mapped get cleared. I have looked through my code and it seems to look alright, but...
My first thought was that I had somehow messed up identity paging, so I used Bochs' debugger to look
at the page tables. It reported that all the memory my kernel was using was identity paged, and read/write.
It isn't a problem with the GDT either since I'm using a flat memory model.
I do have exception handlers for a page fault which print what caused it, but no exception is thrown.
I don't think it is a problem with my page frame allocator since it seems to return only pages whose
bits are marked as "free," as it should, and seems to work for the initial identity paging.
Here is the memory map provided by GRUB, probably via the BIOS:
And here is the page frame information I get. My kernel is loaded from 0x00100000. The rest of memory below it is supposed to be identity paged as well.
This is what is shown before I initialize the heap or any kind of virtual memory management, but after paging is enabled:
The lower 3 nibbles in the DWORDs for 0x00000000 - 0x0009F000 are cleared, when they should be set. I am making sure to memset the entire bitmap to all bits set before parsing the memory map. Does anybody have an idea as to what could be going on?
Problem solved, it was just me being stupid. I wasn't watching where I was writing memory and was somehow anding the first few entries with 0xFFFFF000 to get a page... Now onto the virtual memory manager.
About 5 days ago I got paging to work, and I assumed my physical memory manager was manageable because of it.
However, now I am working on heap creation and allocation functions, and have exposed what I believe to be a bug
in my physical memory management.
I use a bitmap-based allocator, for its space and simplicity. The bug is like this:
Basically, the last 12 bits in a bitmap for most of lower memory up to about where
VGA memory is mapped get cleared. I have looked through my code and it seems to look alright, but...
My first thought was that I had somehow messed up identity paging, so I used Bochs' debugger to look
at the page tables. It reported that all the memory my kernel was using was identity paged, and read/write.
It isn't a problem with the GDT either since I'm using a flat memory model.
I do have exception handlers for a page fault which print what caused it, but no exception is thrown.
I don't think it is a problem with my page frame allocator since it seems to return only pages whose
bits are marked as "free," as it should, and seems to work for the initial identity paging.
Here is the memory map provided by GRUB, probably via the BIOS:
Code: Select all
Base End Length Type
---------- ---------- ---------- --------
0x00000000 0x0009EFFF 636 KB usable
0x0009F000 0x0009FFFF 4 KB unusable
0x000E8000 0x000FFFFF 96 KB unusable
0x00100000 0x03FEFFFF 64448 KB usable
0x03FF0000 0x03FFFFFF 64 KB unusable
0xFFFC0000 0xFFFFFFFF 256 KB unusable
This is what is shown before I initialize the heap or any kind of virtual memory management, but after paging is enabled:
Code: Select all
Page Frame Information
Base End Mask
0x00000000 - 0x0001F000: 0xFFFFF000
0x00020000 - 0x0003F000: 0xFFFFF000
0x00040000 - 0x0005F000: 0xFFFFF000
0x00060000 - 0x0007F000: 0xFFFFF000
0x00080000 - 0x0009F000: 0xFFFFF000
0x000A0000 - 0x000BF000: 0xFFFFFFFF
0x000C0000 - 0x000DF000: 0xFFFFFFFF
0x000E0000 - 0x000FF000: 0xFFFFFFFF
0x00100000 - 0x0011F000: 0xFFFFF000
0x00120000 - 0x0013F000: 0x00000000
Problem solved, it was just me being stupid. I wasn't watching where I was writing memory and was somehow anding the first few entries with 0xFFFFF000 to get a page... Now onto the virtual memory manager.