Page Fault on real hardware

[Wajidali Whowe]

Dear all,
 
I also tried the  x86-mp_vPCI_defconfig and x86-native_defconfig (For both of them I only deactivated PMEM support) and now they resulted in the following outputs, where the PC might also not be seen, i.e. there is no page fault but the Trap 13: 
 ..
 ..
 vmlinuz . | main thread will be 414
 vmlinuz . | l4x_register_pointer_section: addr = 006a8000 size = 2072576
 vmlinuz . | section-with-init: virt: 0x6a8000 to 0x8a1fff [2024KiB]
 vmlinuz . | section-with-init: Phys: ....
 ..
 ..
vmlinuz . | Loading: rom/ramdiskfs.tar.gz 
vmlinuz . | INITRD: Size of RAMdisk is 32768KiB
vmlinuz . | RAMdisk from 18c000000 to 1ac00000 [32768KiB] 
Die message: Trap: 13
vmlinuz . | panic: going to sleep forever, bye


Would it be possible to find out the specific definitions for the Traps? For instance does Trap number (in our case 13) tell about the reasons? 

Best Regards, 



________________________________
 From: Wajidali Whowe <whowe123 at yahoo.com>
To: Wajidali Whowe <whowe123 at yahoo.com>; Adam Lackorzynski <adam at os.inf.tu-dresden.de>; "l4-hackers at os.inf.tu-dresden.de" <l4-hackers at os.inf.tu-dresden.de> 
Sent: Monday, October 29, 2012 12:55 PM
Subject: Re: Page Fault on real hardware
 

Dear Adam, 

I tried for objdump and searching for "47356" not "473569", I found the following output: 

00047350 <rcu_barrier_bh>:
   47350:       55                      push   %ebp
   47351:       ba 84 4e 02 00          mov    $0x24e84,%edx
   47356:       89 e5                   mov    %esp,%ebp
   47358:       83 ec 14                sub    $0x14,%esp
   4735b:       8d 45 f8                lea    -0x8(%ebp),%eax

I guess that this is related with the RCU and i tried different options for the RCU by changing Processor related options like PREEMPT etc... However, could not succeed in passing through the RCU system, each time different errors show up. 

Would it be possible to completely remove the RCU system? do you have a tip on this? Because I could not unfortunately disable it... 

Best Regards, 



________________________________
 From: Wajidali Whowe <whowe123 at yahoo.com>
To: Adam Lackorzynski <adam at os.inf.tu-dresden.de>; "l4-hackers at os.inf.tu-dresden.de" <l4-hackers at os.inf.tu-dresden.de> 
Sent: Monday, October 29, 2012 11:24 AM
Subject: Re: Page Fault on real hardware
 

Dear Adam, 
thank you very much for your fast reply. I have checked once again the boot parameters for kernel and here is the line to boot up the linux: 

L4.default_loader:start(
        {
        },
        "rom/vmlinuz.android mem=256M console=ttyLv0 ramdisk=rom/rootfs.tar.gz root=1:0 ramdisk_size=32768 l4x_rd=rom/rootfs.tar.gz init=/etc/preinit"); 

In other words, the console parameter is already set as you pointed out. However, I will try the gdb/objdump option and inform you about it if I might successfully test it with gdb/objdump. 

Best Regards, 


________________________________
 From: Adam Lackorzynski <adam at os.inf.tu-dresden.de>
To: l4-hackers at os.inf.tu-dresden.de 
Sent: Friday, October 26, 2012 7:44 PM
Subject: Re: Page Fault on real hardware
 
Hi,

On Thu Oct 25, 2012 at 09:18:30 -0700, Wajidali Whowe wrote:
> I have been trying to run L4linux on a real hardware (x86 PC). Everything seems fine once I try the image with the qemu, however the following error appears on the real hardware: 
> 
> ..
> ..
> ..
> vmlinuz . | main thread will be 413
> vmlinuz . | l4x_register_pointer_section: addr = 005e6000 size 929792
> 
> vmlinuz . | section-with-init: virt: 0x5e6000 to 0x6c8fff [908KiB]
> 
> vmlinuz . | section-with-init: virt: ....
> 
> ..
> ..
> ..
> vmlinuz . | Loading: rom/ramdiskfs.tar.gz
> 
> vmlinuz . | INITRD: Size of RAMdisk is 32768KiB
> 
> vmlinuz . | RAMdisk from 188800000 to 1a800000 [32768KiB] 
> 
> vmlinuz . | Page fault (non-resolved): pfa=0 pc=473569
> 
> Die message: Trap: 14
> vmlinuz .
 | panic: going to sleep forever, bye
> 
> 
> Would you please have an idea or a suggestion for this problem?

Do you have console=ttyLv0 on the linux command line? That would
probably give an ooops-printout with much more info, given it is already
that far in booting up that this works. Alternatively you can check with
gdb/objdump of vmlinux what's at and around 0x473569 to figure out
what's going on.



Adam
-- 
Adam                adam at os.inf.tu-dresden.de
  Lackorzynski         http://os.inf.tu-dresden.de/~adam/

_______________________________________________
l4-hackers mailing list
l4-hackers at os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers



_______________________________________________
l4-hackers mailing list
l4-hackers at os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://os.inf.tu-dresden.de/pipermail/l4-hackers/attachments/20121029/2e16ef89/attachment.htm>