Physical Memory Manager [Debugging Help]

[oib111]

Part of my pmm_init() function is to initialize regions of memory (as specified in the memory map), and this has been causing problems for a while now. It would hang when trying to initialize the fourth region specified in the memory map (which happened to have the largest size). For some reason pmm_init_region() would stop in the middle of what it was doing. A friend suggested to change my optimization so I set my optimization to "Full Optimization /Ox" (I'm using Visual Studio) and that seemed to fix the problem, but when I went to test out my kernel on my laptop I had the same problem. It just hung. I remembered that before it was hanging on the biggest region so I recompiled my kernel to print out the size of each memory region and then booted it up. Sure enough, the size of the region it was hanging on was pretty big, about 1GB. But I don't know where to go from here...this seems like a compiler error of sorts, but I'm not sure how to fix that?

[neon]

1GB physical memory region? How much physical memory do you have in your laptop? I would verify that the region itself is correct and free to use. Also, look for anything suspicious in the bochs crash log.

[oib111]

Just looked at it. It's size is 0x3F6A0000, or 1070202880 bytes. 1070202880/(1024^3)=0.9967GB...so yeah almost 1GB.

EDIT:

So I thought...well why not just split the regions into smaller chunks and initialize it chunk by chunk? So I tried doing that except that it still hangs. So once again I'm a bit confused as to what's going on...I don't think it's my code, but just incase:

snippet from pmm_init()

Code: Select all

035:                 // make sure the memory region is usuable
036:                 // types 2, 4, 5 (reserved, ACPI NVS, bad) are all unavailable for use
037:                 if(memmap[i].type == 1 || memmap[i].type == 3) {
038:                         // the code tends to break on regions very big, so check
039:                         // for a region bigger or equal to 1MB in size, and divide it 
040:                         // by 0x10 (16) to break it into manageable chunks
041:                         if(memmap[i].sizeLo >= 0x100000) {
042:                                 // calculate the size of the smaller chunk
043:                                 unsigned int size = memmap[i].sizeLo/16;
044:                                 for(j = 0; j<16; j++) {
045:                                         // initialize the region chunk by chunk
046:                                         pmm_init_region(memmap[i].startLo+(size*j), size);
047:                                 }
048:                         }
049:                         // region is a manageable size
050:                         else {
051:                                 // initialize region for use
052:                                 pmm_init_region(memmap[i].startLo, memmap[i].sizeLo);
053:                         }
054:                 }

[Firestryke31]

Could you post the code for "pmm_init_region()"? Because if that's where the problem is, you should be trying to fix that instead of working around it.

[oib111]

Sure thing:

pmm_init_region()

Code: Select all

181: void pmm_init_region(unsigned int start, unsigned int size) {
182:         unsigned int align = start/BLOCK_ALIGN;
183:         unsigned int blocks = size/BLOCK_SIZE;
184:         while(blocks > 0) {
185:                 // unset the bit
186:                 pmm_unset_bit(align++);
187:                 // decrease the amount of used blocks
188:                 uBlocks--;
189:                 blocks--;
190:         }
191: }

[neon]

Is it possible that the bitmap is overwriting regions of memory that it should not? If you run it in bochs debugger with a similar RAM size, do a ctrl+c when it appears to stop in that routine to break into the debugger and check the state of everything. Im guessing memory corruption.

If you have your PMM display the status of its "blocks/physical frames" usage through each iteration (in pmm_init_region), look for anything strange with the returned values or anything that can cause problems.

[oib111]

It might be memory corruption...but on a different but not totally unrelated note I think there's a problem with how I'm finding free blocks of memory. First off, I make sure to set the unusable parts of the first 1MB of memory as being used, but somehow the when I do a test and allocate some blocks of memory I get:

Code: Select all

p: 0x0
p2: 0x1000
p3: 0x2000

For p I'm not sure if somehow pmm_alloc_block() didn't find anything or if it's messing up and seeing bit 0 as free. Neither makes sense. p2 and p3 is fine, but my question is why it would be at 0x1000 and 0x2000 instead of 0x500 and 0x1500?

[neon]

Hello,

It has to do with page alignment. Pages must be 4k (0x1000) aligned thus the physical frame allocator always returns a pointer that is page aligned on a free block. You can of course change this if you do not plan on using paging of virtual memory. During initialization of the mananger, do you set the first region (bit 0 in the bitmap) as being used? This should reserve the first 4k from ever being modified so the first allocation will be on 0x1000.

[oib111]

Forgot the everything was page aligned haha. Forgot to set bit 0...well after about 30 minutes of messing around with my code I fixed all of my problems with my physical memory manager except of course for the problem this thread was started because of. Think I'll test for memory corruption tomorrow.

EDIT:

Somehow all the problems I just fixed fixed the original problem....hell...yeah.