Hi Ayan, Are you using the toolkit release?
Your observations are correct and from your elf output it seems like system is working fine. Incase you are using some prebuilt binary of hypervisor(as is the case with toolkits), the contain configuration is pre-supplied to it and will not go above this settings I think. On Wed, 2012-07-18 at 20:50 +0530, AYAN KUMAR HALDER wrote: > > Hi Amit, > > I have checked the elf file for "hello world" and confirmed that > there are no RWX pages > > I was debugging the python build script to see if it is able to read > the elf sections properly or not. I added some prints( to > display adresses of various sections) in > tools/pyelf/elf_section_info.py in elf_loadable_section_info(). The > following were the logs:- > rw_sections_start 0xc0003000 > rw_sections_end 0xc0008000 > rx_sections_start 0xc0000000 > rx_sections_end 0xc0002190 > > But while executing I got the following logs:- > > > code0: Mapping 0x3000 bytes as RX from 0x84000000 physical to > 0xc0000000 virtual for project0 > code0: Mapping 0x2000 bytes as RW from 0x84003000 physical to > 0xc0003000 virtual for project0 > > fault_ipc_to_pager: Sending ipc from 1 to 1, > faulty_address=0xc0007ff8, faulty pc=0xc0000014 > > tid=0x00000001 > Unhandled kernel data abort at address 0x00000008 > FAR:0x00000008 > PC:0xf000e380 > Unhandled kernel abort. > Kernel panic. > Halting system... > > > I can see that the RX section has been mapped correctly for 0x3000 > bytes, but the RW section should have been mapped for 0x5000 bytes > whereas it has been actually mapped for 0x2000 bytes. And the faulty > virtual address 0xc0007ff8 is within our range of 0xc0008000. > > Therefore, please help me to locate the script where the mapping is > defined. > I tried to make some changes in linker.ld script( eg . += 0x8000 in > bss section ), but it did not make any difference. > > (Please find my final.elf for your reference. Please execute it on > Pandaboard to observe similar behavior ). > > Regards, > Ayan Kumar Halder > > On Mon, Jul 9, 2012 at 10:24 PM, Amit Mahajan > <amit.maha...@b-labs.com> wrote: > On Mon, 2012-07-09 at 20:14 +0530, AYAN KUMAR HALDER wrote: > > Hi Amit, > > > > Thanks for the prompt and detailed explanation. > > > > I had the same understanding, but now I have experienced a > different > > behavior with Pandaboard ES (OMAP- 4460). > > > > I have declared a global static variable as (in my > project) :- > > static char utcb[THREADS_TOTAL * ( 13 )] > L4_ALIGN(UTCB_SIZE); > > With this, my program got executed successfully. > > > > The logs were as follows:- > > code0: Mapping 0x3000 bytes as RX from 0x84000000 physical > to > > 0xc0000000 virtual for project0 > > code0: Mapping 0x2000 bytes as RW from 0x84003000 physical > to > > 0xc0003000 virtual for project0 > > In __l4_threadlib_init > > c0003100 = address of utcb ( starting address of array ) > > c0004e28 = address of &utcb + 1 ( last address of array ) > > > > Thus as we can see address accessed was 0xc0004e28 which is > within the > > permissible range of ( 0xc0003000 + 0x2000 = 0xc0005000 ) > > > > When I modified it as follows:- > > static char utcb[THREADS_TOTAL * ( 14 )] > L4_ALIGN(UTCB_SIZE); > > > > The logs were as follows:- > > code0: Mapping 0x3000 bytes as RX from 0x84000000 physical > to > > 0xc0000000 virtual for project0 > > code0: Mapping 0x2000 bytes as RW from 0x84003000 physical > to > > 0xc0003000 virtual for project0 > > In __l4_threadlib_init > > c0003100 = address of utcb ( starting address of array ) > > c0004f28 = address of &utcb + 1 ( last address of array ) > > > > Thus as we can see address accessed was 0xc0004f28 which is > within the > > permissible range of ( 0xc0003000 + 0x2000 = 0xc0005000 ) > > > > But When I modified it as follows:- > > static char utcb[THREADS_TOTAL * ( 15 )] > L4_ALIGN(UTCB_SIZE); > > It caused kernel panic > > > > The logs were as follows:- > > code0: Mapping 0x3000 bytes as RX from 0x84000000 physical > to > > 0xc0000000 virtual for project0 > > code0: Mapping 0x2000 bytes as RW from 0x84003000 physical > to > > 0xc0003000 virtual for project0 > > fault_ipc_to_pager: Sending ipc from 1 to 1, > > faulty_address=0xc0005060, faulty pc=0xc00016a8 > > tid=0x00000001 > > Unhandled kernel data abort at address 0x00000008 > > FAR:0x00000008 > > PC:0xf000e380 > > Unhandled kernel abort. > > Kernel panic. > > Halting system... > > > > Here, the array had an address range of 0xc0003100 till > 0xc0005028 > > ( 0xc0004f28 + 100 ) which lies beyond the permissible range > > 0xc0003000 to 0xc0005000 ( 0xc0003000 + 0x2000 - as seen > from kernel > > logs). > > > > Ok you need to check 2 things here: > > 1. Check the elf file of the hello world container and do a > readelf on > it to make sure it is having correct number of RX and RW > pages. It > should not have any RWX section. > > 2. If 1. looks fine, then the problem is in Codezero's reading > of elf > sections at load time. These manipulations are done in some > python > script under codezero/config. Find this script and add some > prints in it > so see if it is manipulating container's section properly. > > > > -- > Thanks, > Amit Mahajan > > > > -- Thanks, Amit Mahajan _______________________________________________ codezero-devel mailing list codezero-devel@lists.l4dev.org http://lists.l4dev.org/mailman/listinfo/codezero-devel_lists.l4dev.org
