Paging initialization:

[distantvoices]

Hey folks, I am kinda stuck!

I am now to build the memory management module for my kernel-experiment. I have read some sources and some information material, but to get it work is still something different. so this is what
I want to do to initialize my pagetables and to get some bookkeeping about them:

these are the book keeping structures:
typedef struct{
ulong_t block_adresse;
uint_t block_laenge;
int block_belegt; // 1=belegt, 0=nicht belegt -> info about used blocks
} speicherseite; -> the pageframe

struct speicher_verwaltung{
speicherseite *block; //a pointer to scroll an easy way throu an huge array
speicherseite seite[MEM_GROESSE]; -> the array of pageframes. assume mem groesse is about 8192.
};

the page directory:

ulong_t *page_directory = (ulong_t *) 0x40000;
ulong_t *page_tabelle[NR_PAGEFRAMES]; ->NR_PAGEFRAMES= 1024

Here is the code in question which does not what i expect it to do:

void page_tabellen_ausfuellen(){
ulong_t adresse = 0;
ulong_t *page_table_address = (ulong_t *) 0x41000;
uint_t q; uint_t z;
speichertabelle.block=&speichertabelle.seite[0];
adresse=0;
for(q=0;q<8;q++){
for(z=0;z<1024;z++){ page_tabelle[q][z]=adresse|PAGE_ATTRIBUT_SUPERVISOR_RW_VORHANDEN;
speichertabelle.block->block_adresse=adresse;
speichertabelle.block->block_laenge=4096;
speichertabelle.block->block_belegt=0;
speichertabelle.block++;
adresse+=4096;
}
page_table_address=page_table_address+4096;
*page_tabelle=(ulong_t *)page_table_address;
}

after this code I fill in the page directory:

for(q=0;q<8;q++){
page_directory[q]=*page_tabelle[q]|PAGEATTRIBUT; -> SUper visor present
}

for(q=8;q<1024;q++){
page_directory[q]=0|PAGEATTRIBUT ;-> Supervisor not present
}

}

this should be the initialization routine for setting up the paging structures. but I have the feeling as if there is something wrong, But I just can't find it. It throws an exception to be exactly.and after that it triple faults.

could you guys pls help me out of that?

stay safe.

[Pype.Clicker]

i'm sorry to say this, but all this variable names in Germ@n are _very_ hard to follow for me .. i'll try nonetheless ...

[distantvoices]

Sorry for that. I am so used to choose german names fr my variables (I am mainframe programmer - mainly cobol ) that i forget to rename them for you.

For now I have another question: Would it be easier for bookkeeping physical memory to keep track of used/free pages in a bitmap, where one bit represents one 4kbyte-page? It would ease my life in order that I can get rid of those structures. (Just use them then for heap control).

thank you in advance

stay safe

[Pype.Clicker]

yes, imho the bitmap is the best compromise, provided that you come with a small extra pointer like *lastfreed, lowest-absolute-free and highest-free ... This way, yu can improve the efficency of the search by eliminating the need for scanning completely used regions ....

I'm working on a new techniques that would group bits into clusters and give completely full clusters a link to the next free or partially free area, which should allow constant-time allocation and free, rather than maybe linear degenerating bitmap ...

[distantvoices]

Well, I have changed the manner to initialize my paging, and now reserve some space for the page directory and the page tables in my asm-module: page_directory: resb 4096, page_table: resb 4096.

These i fill in in c.

It activates paging, it still displays messages upon the screen, afterwards,

BUT

My interrupt handlers are gone: they do not do any thing any more. It just hangs or triple faults: It feels as if the paging changes some addresses, so that the interrupt handlers are located at an other address.

How do I avoid THIS Problem? Has i t something to do with 4 k alignment of the page directory?

thanks very much!

gosh, this drives me to insanity *lol*

[Pype.Clicker]

If you have set up 1:1 mapping, interrupt handling should not be modified ... Are you sure your stack has been mapped as well ?

[distantvoices]

This is a good Hint.

It looks as if the return adresses,which are usually on the stack, can't be found any more.

I gonna check this issue.

Merci beaucoup, Pype.

[Pype.Clicker]

my pleasure

[chrisa128]

Hi all,

I don't want to start a new thread for this (simple) question.

Does GRUB enable the A20 Gate? If it doesn't then this is what is causing my kernel to Triple Fault!

[Pype.Clicker]

this is so much off-topic... Can't you really open a new thread or find a topic about GRUB ? Did you ever tried a g00gle search?

[chrisa128]

Sorry, it was just a sudden brainwave and I was unable to do anything about it at the time as I was on my mobile and laptop.

The reason I am asking it in this thread is because when I enable Paging it causes a triple-fault, and I kinda took it for granted that GRUB enabled the A20 gate for me that I forgot completly about it until I saw this thread...

I will now go and look on google becuase you learn best when you do things for yourself...

[distantvoices]

chrisa128:

google finds most things for you.

ad paging:

Now, I have found out, that my stack is ok. After Enabling paging, I performed some nested function calls (p.e. printf()), and they worked fine.

I think now, that I have to install my interrupt handlers in the idt on runtime, after having enabled paging. I have my IDT created as a static table at compile time, where each and every handler is already installed in. So it is VERY likely, that The bug is buried in my idt.

This is nasty, but no problem. I have already experimented with building IDT at run time, It just didn't work. such a shame...

stay safe ...

[Pype.Clicker]

your page fault handler should better be installed *before* paging is enabled ...

i also thing it might be time for you to search what are the causes of that page fault ... Do you have the content of CR2 already ? and do you know what the faulty instruction is ?... once you have those 2 informations, you can go back to your disassembled code and see what register / register combination is leading to a page fault, and so check whether your paging init is wrong or the code you call after that paging init ...

[distantvoices]

Pype, I have already a default exception handler installed.

The Processor would put the faulty address in register cr2 and fire page fault exception. At least it would find SOMETHING in my idt: the default handler. But it just hangs.

I would have debugged it in bochs. bochs does not like writing to port 20 and so forth. I have posted it in another thread.

[distantvoices]

Well, the smallest bugses are the idiots cradle...

In my enable-paging stuff, there was this OBVIOUS Bug, that has hidden so long so successful from my glance:

mov eax,cr0
AND eax,0x80000000 --> Such a shame!
mov cr0,eax

I changed the AND to an OR and suddenly it did what I expect it to do. Paging works more or less. (It triple faults, cuz I handed over some faulty adresses ... gonna check this out)

Thanks for help never the less.