Paging Triple Fault
-
- Member
- Posts: 190
- Joined: Tue Sep 26, 2006 1:40 pm
- Libera.chat IRC: Nokurn
- Location: Ontario, CA, USA
- Contact:
Ugh, the rewrite didn't do anything! Here's the output from Bochs:
So I have to inspect the paging code and IDT code...again. Terrible.
Code: Select all
00025849647d[CPU0 ] PDE: entry not present
00025849647d[CPU0 ] page fault for address 80000011 @ 00101729
00025849647d[CPU0 ] exception(0x0e): error_code=0002
00025849647d[CPU0 ] interrupt(): vector = 14, INT = 0, EXT = 1
00025849647d[CPU0 ] interrupt(): gate descriptor is not valid sys seg (vector=0x0e)
00025849647d[CPU0 ] exception(0x0d): error_code=0072
00025849647d[CPU0 ] interrupt(): vector = 8, INT = 0, EXT = 1
00025849647d[CPU0 ] interrupt(): gate descriptor is not valid sys seg (vector=0x08)
00025849647d[CPU0 ] exception(0x0d): error_code=0042
-
- Member
- Posts: 2566
- Joined: Sun Jan 14, 2007 9:15 pm
- Libera.chat IRC: miselin
- Location: Sydney, Australia (I come from a land down under!)
- Contact:
I had the same problem when following JamesM's tutorials - for some weird reason I kept page faulting at 0x80000011, which is the CR0 value.
I ended up scrapping that code and writing my own, but it wouldn't hurt to step through the code in the Bochs debugger to try to figure out how it's happening.
I ended up scrapping that code and writing my own, but it wouldn't hurt to step through the code in the Bochs debugger to try to figure out how it's happening.
-
- Member
- Posts: 190
- Joined: Tue Sep 26, 2006 1:40 pm
- Libera.chat IRC: Nokurn
- Location: Ontario, CA, USA
- Contact:
pcmattman: I've scrapped the code several times, tried two different versions of it, written my own, and used the one off of OSDever.net. None of them worked. With this latest rewrite of the code, there are some new messages in the Bochs debug log, and none about the gates. After going through the code with the debugger I've come to the same place I was before: when the paging flag is set in CR0, the triple fault occurs
"mov eax, cr0" is the disassembly of the code at EIP
Bochs debug output, source code.
"mov eax, cr0" is the disassembly of the code at EIP
Bochs debug output, source code.
original code looks fine, except the enable paging part.
your switch_page_directory function is fine, but the part in it that enable's paging (apparently) causes the problem. move it out of that function, and into a new function, say, enable_paging.
(it's in ASM)
should work then.
(it's in ASM)
Code: Select all
[global _enable_paging]
_enable_paging:
mov cr0, eax
or eax, 0x80000000
mov eax, cr0
ret
-
- Member
- Posts: 2566
- Joined: Sun Jan 14, 2007 9:15 pm
- Libera.chat IRC: miselin
- Location: Sydney, Australia (I come from a land down under!)
- Contact:
If you read the Intel Manuals (Volume 3A, exception reference section) you find that CR2 holds the virtual address of the faulting address. Therefore when your CR2 value when Bochs triple faults is 0x80000011, you know something weird is going on.
You don't have an entry for 0x80000000 in your page directory or tables, so Bochs complains about the present bit .
You don't have an entry for 0x80000000 in your page directory or tables, so Bochs complains about the present bit .
-
- Member
- Posts: 190
- Joined: Tue Sep 26, 2006 1:40 pm
- Libera.chat IRC: Nokurn
- Location: Ontario, CA, USA
- Contact:
Yes, I knew that CR2 contained the faulting address. That's why I said that CR2==CR0 was weird. What I'm struggling with is getting the damned thing to work. Might CPaging::SwitchPageDir really be the problem?
- zaleschiemilgabriel
- Member
- Posts: 232
- Joined: Mon Feb 04, 2008 3:58 am
What's this:
00028889748i[CPU0 ] >> mov eax, dword ptr ss:[ebp+0x8] : 8B4508
?
That doesn't look like "mov eax, cr0" to me.
I use the FASM manual as a guideline for the Intel Instruction Set and it says that the mov instruction can be used to transfer a global register to a control register, but it doesn't say anything about using it to copy memory to a control register. The best way is to use the eax register. That always worked for me.
00028889748i[CPU0 ] >> mov eax, dword ptr ss:[ebp+0x8] : 8B4508
?
That doesn't look like "mov eax, cr0" to me.
I use the FASM manual as a guideline for the Intel Instruction Set and it says that the mov instruction can be used to transfer a global register to a control register, but it doesn't say anything about using it to copy memory to a control register. The best way is to use the eax register. That always worked for me.
DeviOuS - what a stupid name
Just had a look at the code above (where you enable paging),
What's the use of the '&' in "&dir->tables_phys"? AFAICS, 'tables_phys' is defined as an array of ints, so using 'dir->tables_phys' should give you the starting address of the array (=the base address of the page directory), which is what you want to put into cr3, don't you? If this piece of code gives you a borked value, it's likely that the mmu complains about invalid page tables. Please let me know if it makes a difference,
cheers
joe
Code: Select all
__asm__ __volatile__ ("mov %0, %%cr3" : : "r" (&dir->tables_phys));
cheers
joe
- zaleschiemilgabriel
- Member
- Posts: 232
- Joined: Mon Feb 04, 2008 3:58 am
You know I think he's right! tables_phys IS the address you're supposed to be putting in there, not &tables_phys, which is the address of the address...JoeKayzA wrote:Just had a look at the code above (where you enable paging),What's the use of the '&' in "&dir->tables_phys"? AFAICS, 'tables_phys' is defined as an array of ints, so using 'dir->tables_phys' should give you the starting address of the array (=the base address of the page directory), which is what you want to put into cr3, don't you? If this piece of code gives you a borked value, it's likely that the mmu complains about invalid page tables. Please let me know if it makes a difference,Code: Select all
__asm__ __volatile__ ("mov %0, %%cr3" : : "r" (&dir->tables_phys));
cheers
joe
OMG. If this is the way it's in JamesM's tutorial maybe he should change it. Weird... I think I saw this problem before somewhere... I'm having deja-vu.
Anyway, this kind of bugs usually make me laugh for days... You can't go wrong with C/C++! Yes you can! Always!
DeviOuS - what a stupid name