Second Page Mapping Causes OS To Crash
Posted: Tue Jul 02, 2024 10:45 pm
Hi,
When ever I map my second page, and then try to use my printing function it will crash the OS, this happens no matter the address for the first or even for the second page and I can run other code before the printing function that will still work.
https://github.com/maxtyson123/MaxOS/tr ... Management
More Deatails:
After sucessfully mapping an address:
My logging function causes the OS to break, however the reason for this is odd.
Using GDB, I inspected my function:
Which is correct, but when diving a layer deeper into the first line of the function (which is to print a header)
Which suggest to me that some how ive overriten something somewhere with my page mapping?
Registers at the time of crash
When inspecting the page mapping in qemu, It looks like physical address 0x210000 has been mapped 146 times.The TLB only seems to be "dirty" like that after it crashes, for instance, it is as expected after writing the new page, and even during interrupt handling of the crash. I Also notice that we running with debugger it is filled with 0x20..... instead of 0x21......
It seems like as soon as that second entry is set the next print fails to execute.
When ever I map my second page, and then try to use my printing function it will crash the OS, this happens no matter the address for the first or even for the second page and I can run other code before the printing function that will still work.
https://github.com/maxtyson123/MaxOS/tr ... Management
More Deatails:
After sucessfully mapping an address:
Code: Select all
physical = {MaxOS::memory::physical_address_t *} 0xfee00000
virtual_address = {MaxOS::memory::virtual_address_t *} 0xffffffff7ee00000
Using GDB, I inspected my function:
Code: Select all
void _kprintf_internal(uint8_t type, const char* file, int line, const char* func, const char* format, ...)
...
type = {uint8_t} 0 '\000' [0x0]
file = {const char *} 0xffffffff801b0ba0 "/home/max/MaxOS/kernel/src/memory/physical.cpp"
line = {int} 293 [0x125]
func = {const char *} 0xffffffff801b0c63 "map"
format = {const char *} 0xffffffff801b0c97 "Mapped: 0x%x to 0x%x\n"
Code: Select all
pre_kprintf(const char* file, int line, const char* func, uint8_t type)
...
file = {const char *} 0xffffffff80103f7d ""
line = {int} -1 [0xffffffff]
func = {const char *} 0xffffffff801c5a18 "p\226\033\200\377\377\377\377"
type = {uint8_t} 224 '\340' [0xe0]
Registers at the time of crash
Code: Select all
rax 0xffffffff801b0ba0 -2145711200
rbx 0x2 2
rcx 0x0 0
rdx 0xffffffff801b0c63 -2145711005
rsi 0x125 293
rdi 0xffffffff801b0ba0 -2145711200
rbp 0xffffffff801c21d0 0xffffffff801c21d0
rsp 0xffffffff801c20f8 0xffffffff801c20f8
r8 0xffffffff801b0c97 -2145710953
r9 0xfee00000 4276092928
r10 0x0 0
r11 0x0 0
r12 0x0 0
r13 0x0 0
r14 0x0 0
r15 0x0 0
rip 0xffffffff801010cc 0xffffffff801010cc <MaxOS::hardwarecommunication::InterruptManager::HandleException0x03()>
eflags 0x200083 [ ID IOPL=0 SF CF ]
cs 0x8 8
ss 0x10 16
ds 0x10 16
es 0x10 16
fs 0x10 16
gs 0x10 16
fs_base 0x0 0
gs_base 0x0 0
k_gs_base 0x0 0
cr0 0x80010011 [ PG WP ET PE ]
cr2 0x0 0
cr3 0x1bc000 [ PDBR=444 PCID=0 ]
cr4 0x20 [ PAE ]
cr8 0x0 0
efer 0x500 [ LMA LME ]
mxcsr 0x1f80 [ IM DM ZM OM UM PM ]
It seems like as soon as that second entry is set the next print fails to execute.