pmm initialized values return to 0

[Riposte]

Hello,

I'm currently working on a pmm for my small kernel project and I'm running into an issue when initializing the values. When I call pmm_init, the values for the maximum number of blocks and blocks used are set using the memory available passed by the multiboot info structure. I've checked to ensure these are properly set by returning some of the values from the init function, but if I try to use some getter functions to check the values later, they return 0. It seems like the moment the init function finishes and goes out of scope the values immediately go back to being 0 but I'm not quite sure why that is happening. Any thoughts?

Here is a gist with relevant portions of my main.c along with the output I get at the top as well as my full pmm.c: https://gist.github.com/StevenLaabs/366 ... 7d95d02bd4

Thank you in advance.

Another note: I've tried initializing the variables to some non-zero values when they are first declared and they seem to keep that value, so nothing is overwriting them and it is as if nothing is being changed when pmm_init is called. I've set breakpoints and output values from within the init and am sure it is being called and that the values are correct while within scope of the function.

[Riposte]

Small update: I disassembled the binary to check the addresses used in the getter and init functions were the same and it appears they are as well.
Disassembly for the pmm get and init functions: http://pastebin.com/rcFSTq7g

Edit: I've realized initializing paging and jumping to the higher half address before initializing the pmm solves that problem, but I think I'm still having a hard time understanding what was going on when I was calling the function and it was accessing the same memory each time. If somebody could explain this to me I'd really appreciate it.

[LtG]

Debugging is usually the easiest way to identify the issue, for example using a memory breakpoint, seeing what changes the value, or single stepping from some interesting point onward.

Also would be useful if you gave a bit more specifics, like what getter, what did it return and what was expected?

"It seems like the moment the init function finishes and goes out of scope the values immediately go back to being 0", is the "init" you refer to here the pmm_init or kinit?

After quick look at your code, are you making all of the free ranges in the memory map free in your PMM? That is, are you somewhere excluding (manually) the kernel, the multibootinfo structure, your PMM bitmap, and all other relevant memory? The memory map contains all _usable_ physical memory (ie. RAM), so it includes the memory housing GRUB, multiboot info structs, etc..

In the long term you may also want to sanitize the memory map, IIRC GRUB only provides you with what it got from the BIOS, thus it could have overlapping entries, entries not in order, etc.. You'll want to be as conservative as possible with the memory map as it's "external" data..

[Riposte]

Debugging is usually the easiest way to identify the issue, for example using a memory breakpoint, seeing what changes the value, or single stepping from some interesting point onward.

Also would be useful if you gave a bit more specifics, like what getter, what did it return and what was expected?

"It seems like the moment the init function finishes and goes out of scope the values immediately go back to being 0", is the "init" you refer to here the pmm_init or kinit?

Hi, I was able to fix the problem earlier as I realized I hadn't enabled paging yet so my kernel was not mapped properly and I think I have a better understanding of the problem.

After quick look at your code, are you making all of the free ranges in the memory map free in your PMM? That is, are you somewhere excluding (manually) the kernel, the multibootinfo structure, your PMM bitmap, and all other relevant memory? The memory map contains all _usable_ physical memory (ie. RAM), so it includes the memory housing GRUB, multiboot info structs, etc..

In the long term you may also want to sanitize the memory map, IIRC GRUB only provides you with what it got from the BIOS, thus it could have overlapping entries, entries not in order, etc.. You'll want to be as conservative as possible with the memory map as it's "external" data..

With the code I gave before I was reserving memory for the kernel but I did neglect the other parts. I've reworked the code a bunch and it works better now, thank you for your help!