Page fault when switching to user mode?

[ablakely]

Here's my switch_to_usermode:

Code: Select all

void switch_to_user_mode()
{
	set_kernel_stack(current_task->kernel_stack+KERNEL_STACK_SIZE);

	printf("Attempting to switch to user mode.\n");
	asm volatile("  \
		cli; \
		mov $0x23, %ax; \
		mov %ax, %ds; \
		mov %ax, %es; \
		mov %ax, %fs; \
		mov %ax, %gs; \
								\
	  mov %esp, %eax; \
		pushl $0x23; \
		pushl %eax; \
    \
		pushf; \
		pushl $0x1B; \
		push $1f; \
		iret; \
		1: \
	");

}

which when I call it, results with this.



I'm kinda stuck on this one, any help would be appreciated.

[iansjack]

Well the error code tells you that you tried to write to a page that you weren't authorised to. Your page table should reveal why that is so. Only you know what entries are in your tables and what instruction corresponds to the value in eip.

[MDenham]

Is there a reason why the last push doesn't specify an operand size?

[ablakely]

I believe I have fixed this bug, somewhere in this commit. https://github.com/ablakely/xnix/commit ... a082a31b68

[ablakely]

Although when I loop a fork call it eventually ends up triple faulting after 3-4 seconds.

Is that normal behavior?

BOCHS log:

Code: Select all

00067713491i[CPU0 ] CPU is in protected mode (active)
00067713491i[CPU0 ] CS.d_b = 32 bit
00067713491i[CPU0 ] SS.d_b = 32 bit
00067713491i[CPU0 ] EFER   = 0x00000000
00067713491i[CPU0 ] | RAX=000000000051b000  RBX=00000000dfffffcc
00067713491i[CPU0 ] | RCX=0000000000104428  RDX=00000000c0108814
00067713491i[CPU0 ] | RSP=00000000c00e072c  RBP=00000000e0000014
00067713491i[CPU0 ] | RSI=0000000000053ca3  RDI=0000000000053ca2
00067713491i[CPU0 ] |  R8=0000000000000000   R9=0000000000000000
00067713491i[CPU0 ] | R10=0000000000000000  R11=0000000000000000
00067713491i[CPU0 ] | R12=0000000000000000  R13=0000000000000000
00067713491i[CPU0 ] | R14=0000000000000000  R15=0000000000000000
00067713491i[CPU0 ] | IOPL=0 id vip vif ac vm RF nt of df if tf SF zf af pf cf
00067713491i[CPU0 ] | SEG selector     base    limit G D
00067713491i[CPU0 ] | SEG sltr(index|ti|rpl)     base    limit G D
00067713491i[CPU0 ] |  CS:0008( 0001| 0|  0) 00000000 ffffffff 1 1
00067713491i[CPU0 ] |  DS:0010( 0002| 0|  0) 00000000 ffffffff 1 1
00067713491i[CPU0 ] |  SS:0010( 0002| 0|  0) 00000000 ffffffff 1 1
00067713491i[CPU0 ] |  ES:0010( 0002| 0|  0) 00000000 ffffffff 1 1
00067713491i[CPU0 ] |  FS:0010( 0002| 0|  0) 00000000 ffffffff 1 1
00067713491i[CPU0 ] |  GS:0010( 0002| 0|  0) 00000000 ffffffff 1 1
00067713491i[CPU0 ] |  MSR_FS_BASE:0000000000000000
00067713491i[CPU0 ] |  MSR_GS_BASE:0000000000000000
00067713491i[CPU0 ] | RIP=0000000000103397 (0000000000103397)
00067713491i[CPU0 ] | CR0=0xe0000011 CR2=0x0000000000107700
00067713491i[CPU0 ] | CR3=0x0051b000 CR4=0x00000000
00067713491i[CPU0 ] 0x0000000000103397: (instruction unavailable) page not present
00067713491e[CPU0 ] exception(): 3rd (14) exception with no resolution, shutdown status is 00h, resetting
00067713491i[SYS  ] bx_pc_system_c::Reset(HARDWARE) called
00067713491i[CPU0 ] cpu hardware reset

[FusT]

Your bochs log tells you exactly why it's crashing:

Code: Select all

00067713491i[CPU0 ] 0x0000000000103397: (instruction unavailable) page not present

[MDenham]

Your bochs log tells you exactly why it's crashing:

Code: Select all

00067713491i[CPU0 ] 0x0000000000103397: (instruction unavailable) page not present

That's the third fault in the triple fault; the cause would be whatever the first one is.

(This does bring up the question of why his page fault handler isn't currently present, though.)

[Combuster]

That's the third fault in the triple fault;

No, it has to be the first. A double fault/triple fault can only be invoked if the system is unable to nest the relevant exception handlers. If it can even get as far as to try and execute the first instruction of an exception handler, the entire exception has already been handled from the processor's point of view: all the registers have been set and the return addresses and error codes have been put on the stack, and it is therefore possible to return to the original code even when a new exception or interrupt would fire after that point.

In other words, if an exception is caused by the first instruction of an exception handler, then that starts a separate chain.

[MDenham]

That's the third fault in the triple fault;

No, it has to be the first. A double fault/triple fault can only be invoked if the system is unable to nest the relevant exception handlers. If it can even get as far as to try and execute the first instruction of an exception handler, the entire exception has already been handled from the processor's point of view: all the registers have been set and the return addresses and error codes have been put on the stack, and it is therefore possible to return to the original code even when a new exception or interrupt would fire after that point.

In other words, if an exception is caused by the first instruction of an exception handler, then that starts a separate chain.

Had to think about it for a moment because I forgot that "double fault" has its own handler. You're right; the ordering would probably be #PF>#PF becomes #DF with error code mentioning that the second (or first? It's been a while since I read any sort of reference) fault was a page fault>#PF resets system because triple fault, more likely than not, I believe.

It still brings up the question of why his page fault handler is in a page that's marked "not present", though.

[FusT]

That is the question but there are likely a lot more bugs/problems/design flaws in the code than just this one.
Browsing through the repository it's easy to see all of the paging/heap/multitasking code is based on JamesM's tutorial, which has a lot of problems
I'd especially be looking at this: http://wiki.osdev.org/James_Molloy%27s_ ... page_fault

[Combuster]

It still brings up the question of why his page fault handler is in a page that's marked "not present", though.

Can you even conclude that if we know by fact of a triple fault that an exception handler could not be executed at all?

[MDenham]

It still brings up the question of why his page fault handler is in a page that's marked "not present", though.

Can you even conclude that if we know by fact of a triple fault that an exception handler could not be executed at all?

...We can't even validly conclude that the initial fault was a page fault, because one of the other fault handlers may have swapped out and/or flagged the page with the initial instruction as "not present". (If this were on real hardware rather than in Bochs, this could also be chalked up to #DF leaving EIP undefined. Bochs, however, is somewhat more reasonable and leaves EIP in a well-defined state at the time of a double fault.)

We do know that the last fault was a page fault caused by something being wrong with the double fault handler (either the IDT itself is on a page currently marked "not present", or for #DF it's pointing to something on a page marked "not present"... assuming reasonable code, at least); beyond that, the debug output would be necessary to actually determine what happened prior to that.

[ablakely]

That is the question but there are likely a lot more bugs/problems/design flaws in the code than just this one.
Browsing through the repository it's easy to see all of the paging/heap/multitasking code is based on JamesM's tutorial, which has a lot of problems
I'd especially be looking at this: http://wiki.osdev.org/James_Molloy%27s_ ... page_fault

I had already made that change.

[Techel]

Using inline assembly is a bad idea most of the time. Use an external assembly module.