Fw: Re: Memory mapping in the OKL4
|
|
Gabi Voiculescu
|
_______________________________________________ Developer mailing list [hidden email] https://lists.okl4.org/mailman/listinfo/developer |
||||||||||||||||||
Guanghui, Cheng
|
> You should first ensure that you indeed dump the right virtual address
> range in kdb, and thus that your problem relies in the source. > > From your output it is not clear to me if the memdump happens in the right > space. > > You may want to try 'D' instead of 'd'. That way you can specify in what > space you want the dump made. Thanks for your reply. you are right. When i use 'D' instead of d the output is like this: 3e008000 464c457f 00010101 00000000 00000000 .ELF.... ........ 3e008010 00280002 00000001 00008110 00000034 ..(..... ....4... 3e008020 001310bc 04000002 00200034 00280005 ........ 4. ...(. 3e008030 0019001a 70000001 0012f4c4 001374c4 .......p .....t.. 3e008040 001374c4 00000a30 00000a30 00000004 .t..0... 0....... 3e008050 00000004 00000001 00000000 00008000 ........ ........ 3e008060 00008000 0012ff74 0012ff74 00000005 ....t... t....... 3e008070 00008000 00000001 00130000 00138000 ........ ........ 3e008080 00138000 00000f84 0000c2ac 00000006 ........ ........ 3e008090 00008000 00000004 000000d4 000080d4 ........ ........ 3e0080a0 000080d4 00000020 00000020 00000004 .... ... ....... 3e0080b0 00000004 00000007 00130000 00138000 ........ ........ 3e0080c0 00138000 00000018 00000048 00000004 ........ H....... 3e0080d0 00000004 00000004 00000010 00000001 ........ ........ 3e0080e0 00554e47 00000000 00000002 00000006 GNU..... ........ 3e0080f0 00000010 e52de004 e24dd004 eb000011 ......-. ..M..... It really maps this virtual page starting from 3e008000 to the segment 21 with offset 28000. I compared the output with the debug output of OKLinux published by OKL4 and they are the same. But i have a problem more. Although the 3e008000 has been mapped the page fault still happens in my system. It seems to be not mapped either. Please look at this output: [ 2.337332] syscall_loop: addr=0x3e008110, offset=0x3e000000 [ 2.338843] user_mode_status: 512 [ 2.340124] syscall_loop: regs->mode=1, context.pid=31 [ 2.341465] l4 do page fault return value = 0x80e47fd0 access=1 L_syscal pgd: 0x80edf000 [ 2.343591] l4 do page fault: address=0x8110, access=0x0, regs->mode:1 pgd->pgd:0x80edf000 [ 2.346233] mm->pgd=0x80edf000, pgd_index=0x0 [ 2.347446] handle mm fault, vma->start:0x8000, vma->end:0x138000, pgd:0x80ee306d, pmd:0x80ee306d, pte:0x0 [ 2.350156] pte 0x0 is not present. [ 2.353564] do_linear_fault. [ 2.360133] __do_fault 0x0 [ 2.362764] vm_ops fault. [ 2.365315] file_map: pgoff: 0x0 [ 2.370174] page_to_pfn: 0x80e28 [ 2.373629] __do_fault, vma->start:0x8000, vma->end:0x138000, pte:0x80e28055, pte_t:0x80e28055 [ 2.380194] update_mmu_cache, pte is present. [ 2.384129] okl4_map_page seg:0x15, src_addr:0x28000, virt_addr:0x3e008000, rwx=5, size=1000, last_vstart=0x80e00000, context->space_id=1, attrib=3 --- KD# User: Welcome --- > go [ 2.400319] yes, we need to reschedule [ 2.401869] syscall_loop: addr=0x3e008110, offset=0x3e000000 [ 2.403403] user_mode_status: 512 [ 2.404828] syscall_loop: regs->mode=1, context.pid=31 [ 2.406199] l4 do page fault return value = 0x0 access=1 L_syscal pgd: 0x80edf000 [ 2.410154] l4 do page fault: address=0x8110, access=0x0, regs->mode:1 pgd->pgd:0x80edf000 [ 2.412356] mm->pgd=0x80edf000, pgd_index=0x0 [ 2.413503] handle mm fault, vma->start:0x8000, vma->end:0x138000, pgd:0x80ee306d, pmd:0x80ee306d, pte:0x80e28855 [ 2.420156] pte 0x80e28855 is present. [ 2.421209] update_mmu_cache, pte is present. [ 2.430168] okl4_map_page seg:0x15, src_addr:0x28000, virt_addr:0x3e008000, rwx=5, size=1000, last_vstart=0x80e00000, context->space_id=1, attrib=3 We can see the page fault twice is the same virtual address : 3e008000. So before i doubted this is caused by map operation failure. In fact it is really mapped but the page fault happens in one address again. I am really confused with the behaviour. Thanks a lot. Cheng Guanghui _______________________________________________ Developer mailing list [hidden email] https://lists.okl4.org/mailman/listinfo/developer |
||||||||||||||||
|
Gabi Voiculescu
|
_______________________________________________ Developer mailing list [hidden email] https://lists.okl4.org/mailman/listinfo/developer |
|||||||||||||||||
|
Guanghui, Cheng
|
On Monday 03 August 2009 03:09:36 pm Gabi Voiculescu wrote:
> Can you also give the output of ptab ('p') in kdb, and list spaces 'S'? > > Ptab is how you should check the mapping with kdb. Use the space id to > return the mapping list for your space of interest. 'S' gives you the > entire set of spaces. > > Also you may want to activate some debug messages at okl4 level by > compiling in the kernel's debug print statements. If you are indeed page > faulting it can be handy to locate the exact pagefaulting IP. You could > build your image with using a command with the additional arguments > ENABLE_DEBUG=True DEBUG_TRACE=1. It will make the elf larger, and you will > see many more messages coming from the okl4 kernel. --- KD# User: Welcome --- > listspaces f0024ed8/-1: (idle_thr) f0107e4c/0: (L_timer) (L_syscal) f0107d58/1: (L_1) > ptab Space [current]: 1 Dumping space 0xf0107d58: num = 64 3c000000 [f010ac00]: tree=f010ac00 3e000000 [0010d001]: tree=f410d000 3e000000 [00000000]: tree=f410d000 3e008000 [00f28aae]: phys=00f28000 pg=f410d020 4KB r~x (RWX) user WB domain = 14 3e100000 [0010b401]: tree=f410b400 3e130000 [00000000]: tree=f410b4c0 3e138000 [01070ffe]: phys=01070000 pg=f410b4e0 4KB rwx (RWX) user WB domain = 14 3f800000 [0010b801]: tree=f410b800 3f800000 [00000000]: tree=f410b800 3f804000 [00f2dffe]: phys=00f2d000 pg=f410b810 4KB rwx (RWX) user WB domain = 14 That is all. Thanks. Cheng Guanghui > --- On Mon, 8/3/09, Guanghui, Cheng <[hidden email]> wrote: > > From: Guanghui, Cheng <[hidden email]> > Subject: Re: [okl4-developer] Fw: Re: Memory mapping in the OKL4 > To: [hidden email] > Cc: "Gabi Voiculescu" <[hidden email]> > Date: Monday, August 3, 2009, 5:00 AM > > > You should first ensure that you indeed dump the right virtual address > > range in kdb, and thus that your problem relies in the source. > > > > From your output it is not clear to me if the memdump happens in the > > right space. > > > > You may want to try 'D' instead of 'd'. That way you can specify in what > > space you want the dump made. > > Thanks for your reply. you are right. When i use 'D' instead of d the > output is like this: > 3e008000 464c457f 00010101 00000000 00000000 .ELF.... ........ > 3e008010 00280002 00000001 00008110 00000034 ..(..... ....4... > 3e008020 001310bc 04000002 00200034 00280005 ........ 4. ...(. > 3e008030 0019001a 70000001 0012f4c4 001374c4 .......p .....t.. > 3e008040 001374c4 00000a30 00000a30 00000004 .t..0... 0....... > 3e008050 00000004 00000001 00000000 00008000 ........ ........ > 3e008060 00008000 0012ff74 0012ff74 00000005 ....t... t....... > 3e008070 00008000 00000001 00130000 00138000 ........ ........ > 3e008080 00138000 00000f84 0000c2ac 00000006 ........ ........ > 3e008090 00008000 00000004 000000d4 000080d4 ........ ........ > 3e0080a0 000080d4 00000020 00000020 00000004 .... ... ....... > 3e0080b0 00000004 00000007 00130000 00138000 ........ ........ > 3e0080c0 00138000 00000018 00000048 00000004 ........ H....... > 3e0080d0 00000004 00000004 00000010 00000001 ........ ........ > 3e0080e0 00554e47 00000000 00000002 00000006 GNU..... ........ > 3e0080f0 00000010 e52de004 e24dd004 eb000011 ......-. ..M..... > It really maps this virtual page starting from 3e008000 to the segment > 21 with offset 28000. I compared the output with the debug output of > OKLinux published by OKL4 and they are the same. > But i have a problem more. Although the 3e008000 has been mapped the > page fault still happens in my system. It seems to be not mapped either. > Please look at this output: > [ 2.337332] syscall_loop: addr=0x3e008110, offset=0x3e000000 > [ 2.338843] user_mode_status: 512 > [ 2.340124] syscall_loop: regs->mode=1, context.pid=31 > [ 2.341465] l4 do page fault return value = 0x80e47fd0 access=1 L_syscal > pgd: 0x80edf000 > [ 2.343591] l4 do page fault: address=0x8110, access=0x0, regs->mode:1 > pgd->pgd:0x80edf000 > [ 2.346233] mm->pgd=0x80edf000, pgd_index=0x0 > [ 2.347446] handle mm fault, vma->start:0x8000, vma->end:0x138000, > pgd:0x80ee306d, pmd:0x80ee306d, pte:0x0 > [ 2.350156] pte 0x0 is not present. > [ 2.353564] do_linear_fault. > [ 2.360133] __do_fault 0x0 > [ 2.362764] vm_ops fault. > [ 2.365315] file_map: pgoff: 0x0 > [ 2.370174] page_to_pfn: 0x80e28 > [ 2.373629] __do_fault, vma->start:0x8000, vma->end:0x138000, > pte:0x80e28055, pte_t:0x80e28055 > [ 2.380194] update_mmu_cache, pte is present. > [ 2.384129] okl4_map_page seg:0x15, src_addr:0x28000, > virt_addr:0x3e008000, rwx=5, size=1000, last_vstart=0x80e00000, > context->space_id=1, attrib=3 --- KD# User: Welcome --- > > > go > > [ 2.400319] yes, we need to reschedule > [ 2.401869] syscall_loop: addr=0x3e008110, offset=0x3e000000 > [ 2.403403] user_mode_status: 512 > [ 2.404828] syscall_loop: regs->mode=1, context.pid=31 > [ 2.406199] l4 do page fault return value = 0x0 access=1 L_syscal pgd: > 0x80edf000 > [ 2.410154] l4 do page fault: address=0x8110, access=0x0, regs->mode:1 > pgd->pgd:0x80edf000 > [ 2.412356] mm->pgd=0x80edf000, pgd_index=0x0 > [ 2.413503] handle mm fault, vma->start:0x8000, vma->end:0x138000, > pgd:0x80ee306d, pmd:0x80ee306d, pte:0x80e28855 > [ 2.420156] pte 0x80e28855 is present. > [ 2.421209] update_mmu_cache, pte is present. > [ 2.430168] okl4_map_page seg:0x15, src_addr:0x28000, > virt_addr:0x3e008000, rwx=5, size=1000, last_vstart=0x80e00000, > context->space_id=1, attrib=3 > We can see the page fault twice is the same virtual address : 3e008000. > So before i doubted this is caused by map operation failure. In fact it is > really mapped but the page fault happens in one address again. I am really > confused with the behaviour. > Thanks a lot. > Cheng Guanghui > _______________________________________________ Developer mailing list [hidden email] https://lists.okl4.org/mailman/listinfo/developer |
||||||||||||||||
|
Gabi Voiculescu
|
_______________________________________________ Developer mailing list [hidden email] https://lists.okl4.org/mailman/listinfo/developer |
|||||||||||||||||
| Free Embeddable Forum Powered by Nabble | Help |
