Commit d16f0f Causes Reboot Loop on VMWARE

[itravers]

Commit

d16f0ff6b778d37209f7bd3d68400bb10eef6080

causes a reboot loop on vmware

The commit directly before it runs fine on vmware

32bb02de66679b093299403da499b8c6f21a453e

The only change made was adding the PanicOS welcome screen:

https://github.com/itravers/PanicOS/compare/32bb02de66679b093299403da499b8c6f21a453e...d16f0ff6b778d37209f7bd3d68400bb10eef6080

[itravers]

This HAS to be something to do with paging.

Apparently when we get to the printToScreen function half way through the function at approx the 8th command in the function the kernel size increases from 0x9F18 to 0xAF18 which causes initrd to start at 0x10B000 instead of 0x10A000 which causes usable memory to start at 0x10C000 instead of 0x10D000

before image on qemu https://i.imgur.com/3byqxji.png

after image on qemu https://i.imgur.com/AhE5h1G.png

[itravers]

Some possible tests to try:

1. Increase qemu memory to as much as the vmware guest has.
2. try running iso on boch, adjusting memory to the qemu size, and the vmware size

I'm guessing the problem has something to do with a bug in the identity mapping were doing in the paging system. The fact is that the vmware machine keeps operating until THE ASSEMBLY CODE where we activate paging.

/* Switch the top level page directory to a new one. */
void switch_page_directory(page_directory_t *dir){
  current_directory = dir;
  asm volatile("mov %0, %%cr3":: "r"(&dir->tablesPhysical));
  u32int cr0;
  asm volatile("mov %%cr0, %0": "=r"(cr0));
  cr0 |= 0x80000000; // Enable paging!
  asm volatile("mov %0, %%cr0":: "r"(cr0)); //**<--- VMWARE CRASHES RIGHT HERE**
}

[itravers]

Found this in the vmware logs, logs like it's a triple fault: 2017-10-07T18:19:18.814Z| vcpu-0| I125: Unknown int 10h func 0x0000 2017-10-07T18:19:18.818Z| vcpu-0| I125: Triple fault. 2017-10-07T18:19:18.818Z| vcpu-0| I125: MsgHint: msg.monitorEvent.tripleFault 2017-10-07T18:19:18.818Z| vcpu-0| I125+ A fault has occurred causing a virtual CPU to enter the shutdown state. If this fault had occurred outside of a virtual machine, it would have caused the physical machine to restart. The shutdown state can be reached by incorrectly configuring the virtual machine, a bug in the guest operating system, or a problem in VMware ESX.--------------------------------------- 2017-10-07T18:19:18.819Z| vcpu-0| I125: CPU reset: hard (mode 2)

[itravers]

This may have something to do with it, I might need to figure out how to memset the newly allocated frames to 0

I was also facing the same problem with paging tutorial.But after some searching i found the solution it was happening because as soon as paging is enabled, all address become virtual and to solve it we must map the virtual addresses to the same physical addresses so they refer to the same thing and this is called identity mapping. you can follow this link for further help in implementing Identity Maping. and one more thing you have memset the newly allocated space to zero because it may contain garbage values and memset was not done in tutorial it will work on bochs because it set the space to zero for you but other emulator(qemu) and real hardware are so kind.