OSDev.org

OK people my brain stopped its interacting with outer world, does not recognise programming language patterns any more, I can only write this and then go to sleep, I have no interest in writing a mm until tomorrow -In fact it is 4:14AM now, so tomorrow is 19 hours and 46 Minutes later but untl then I will be ready to go on I think-... Enough chatting please tell me what this bohcsout.txt text means...

...
00000506022e[HD ] device set to 0 which does not exist
00000506315e[HD ] device set to 1 which does not exist
00004109734p[CPU ] >>PANIC<< fetch_raw_descriptor: LDTR.valid=0
00004109734i[SYS ] Last time is 1043287679
00004109734i[CPU ] protected mode
00004109734i[CPU ] CS.d_b = 32 bit
00004109734i[CPU ] SS.d_b = 32 bit
00004109734i[CPU ] | EAX=003ff000 EBX=00011000 ECX=0000007f EDX=0000002e
00004109734i[CPU ] | ESP=0000ffdf EBP=0000fff7 ESI=00003944 EDI=00000005
00004109734i[CPU ] | IOPL=0 NV UP EI PL NZ NA PO NC
00004109734i[CPU ] | SEG selector base limit G D
00004109734i[CPU ] | SEG sltr(index|ti|rpl) base limit G D
00004109734i[CPU ] | DS:0010( 0002| 0| 0) 00001000 000fffff 1 1
00004109734i[CPU ] | ES:0010( 0002| 0| 0) 00001000 000fffff 1 1
00004109734i[CPU ] | FS:0010( 0002| 0| 0) 00001000 000fffff 1 1
00004109734i[CPU ] | GS:0008( 0001| 0| 0) 00000000 000fffff 1 1
00004109734i[CPU ] | SS:0010( 0002| 0| 0) 00001000 000fffff 1 1
00004109734i[CPU ] | CS:0018( 0003| 0| 0) 00001000 000fffff 1 1
00004109734i[CPU ] | EIP=000037a2 (000037a1)
00004109734i[CPU ] | CR0=0xe0000011 CR1=0x00000000 CR2=0x00400000
00004109734i[CPU ] | CR3=0x00010000 CR4=0x00000000
...

Here, I am simply creating an artificial page fault at 0x400000, what does LDTR.valid=0 mean? Do we need an LDT for being able to handle page faults? thanx...

as "fetch_raw_descriptor" says, it seems that you've been loading a segment register (otherwise i don't see why a descriptor reading would be involved)

And the value you stored in that descriptor has its TI bit set, so BOCHS tries to locate the current LDT, but as you didn't set up one, it just ends with garbage.

Maybe you should try to find out where that 0037a2 is in your code and show us the sources of it, but as the instruction seems to be one-byte-long, i bet on a faulty popping (maybe the IRET after your page fault).

037a2 comes to the IRET at the end of page fault handler asm stub. (Down here) Is there anything suspicious about it?

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;   Handler for Page fault.
;   Handles exception 14
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
PAGE_FAULT_HAND:
   cli
   pusha
   push ds
   push es
   push fs
   push gs

      call _page_fault_handler

   pop gs
   pop fs   
   pop es
   pop ds
   popa
   sti
   iret <----0037a2 is here

not directly ... is there some macro that invokes that code or do you have PAGE_FAULT_HAND directly written in your IDT ?

Could i also see the _page_fault_handler code ?

the only thing i see which could prevent your code from working fine is a modification of the stackframe from within the (C?) handler ...

Sure you can see it but currently I am trying to put it working so it is a little bit long and messy. But I have noticed that when I call handler explicitly before creating page fault artificially, code works fine... I mean code sets PDEs and PTEs correctly... Anyway as soon as I can finish problematic code, I can post it... Thanx...

BTW, I do not have a macro, PAGE_FAULT_HAND is an entry in IDT.

i would not "sti" in it, if i were you. If a IRQ handler raises a Page Fault and if PF handler re-enables IRQs, strange results may occur ...
I would rather leave that job to IRET, if i were you.

Hi, code is attached. I have taken some messages out.
prints: prints a message to specfified row and column.
allocate_pt_page(): Allocates 4096 bytes for page table page.
Other functions are there. For this specific case I know what values are returned by functions:
allocate_pt_page() returns 32768. Only this is necessary I think. read_cr2() correctly reads cr2. init_pm() initializes physical memory bitmap, initially 4MB of memory is mapped 1:1 onto virtual memory. So first 1024 pages are set to be used. Page fault is created intentionally at CR2=0x00400000(4MB). Hope I am clear.

[attachment deleted by admin]

Hi, forget about the question, I found the error, I was not poping the error code, I think this is the error. Because when I popped error code at the very very beginning of assembly stub everything started working, anyway thanx, but is that correct?

right. i did forgot there was an error code in #page fault because its value is pretty useless (iirc). otherwise i would have notified you quicker (if it would have been a #segfault, for instance)...