RE: ARM with Qemu

Hi Adam,

>A page-fault above the current stack, so that will probably be the cause for the segfault. Does this >always happen in this way?

In fact I have 2 different exitcodes on the board: 
-	exitcode=0x00000004 :

Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000004
CPU: 0 PID: 1 Comm: init Not tainted 3.16.0-l4 #50
[<0200caa0>] (unwind_backtrace) from [<020055e8>] (show_stack+0x10/0x14)
[<020055e8>] (show_stack) from [<022441e4>] (panic+0x7c/0x1e0)
[<022441e4>] (panic) from [<0201e6d4>] (do_exit+0x708/0x7a0)
[<0201e6d4>] (do_exit) from [<0201e838>] (do_group_exit+0x3c/0x9c)
[<0201e838>] (do_group_exit) from [<020283bc>] (get_signal_to_deliver+0x148/0x490)
[<020283bc>] (get_signal_to_deliver) from [<02006be8>] (do_signal+0x114/0x448)
[<02006be8>] (do_signal) from [<02006fc4>] (do_work_pending+0xa8/0xf8)
[<02006fc4>] (do_work_pending) from [<02008970>] (l4x_pre_iret_work.isra.24.part.25+0x60/0x100)
[<02008970>] (l4x_pre_iret_work.isra.24.part.25) from [<020099f0>] (l4x_vcpu_entry_c+0x274/0x1da8)
[<020099f0>] (l4x_vcpu_entry_c) from [<0000c4ec>] (0xc4ec)
---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000004

-	exitcode=0x0000000b:

Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
CPU: 0 PID: 1 Comm: init Not tainted 3.16.0-l4 #50
[<0200caa0>] (unwind_backtrace) from [<020055e8>] (show_stack+0x10/0x14)
[<020055e8>] (show_stack) from [<022441e4>] (panic+0x7c/0x1e0)
[<022441e4>] (panic) from [<0201e6d4>] (do_exit+0x708/0x7a0)
[<0201e6d4>] (do_exit) from [<0201e838>] (do_group_exit+0x3c/0x9c)
[<0201e838>] (do_group_exit) from [<020283bc>] (get_signal_to_deliver+0x148/0x490)
[<020283bc>] (get_signal_to_deliver) from [<02006be8>] (do_signal+0x114/0x448)
[<02006be8>] (do_signal) from [<0200a210>] (l4x_vcpu_entry_c+0xa94/0x1da8)
[<0200a210>] (l4x_vcpu_entry_c) from [<00000000>] (  (null))
---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b

Nonetheless, on the trace, it always seems to be the same way and the same task problem. So, with the exitcode 0x00000004 I have:

jdb: T
  0% of 32768  Perf:ACor 1=00000000(:e0)                                   index
                         2=00000000(:e0)
vcpu: 003e exc #0 err=0 pc=fb870 sp=bf792ef0 state=2f task=D:44               32
vcpu: 003e ret pc=fb850 sp=bf792ef0 state=2f task=D:44                        31
vcpu: 003e pf  pc=fb850 pfa=fb850 err=80000007 state=2f task=D:44             30
vcpu: 003e ret pc=c4c0 sp=bf792ef0 state=2f task=D:44                         29
vcpu: 003e pf  pc=c4c0 pfa=c4c0 err=80000005 state=2f task=D:44               28
vcpu: 003e ret pc=c4c0 sp=bf792ef0 state=27 task=D:44                         27
vcpu: 003e ret pc=20a6cc0 sp=5c27e90 state=5 task=D:34                        26
vcpu: 003e ipc from D:41 task=D:5 sp=5c27e90                                  25
vcpu: 003e ret pc=2157a94 sp=5c27984 state=5 task=D:34                        24
[…]

And with the exitcode 0x0000000b I can see:

jdb: T
  0% of 32768  Perf:ACor 1=00000000(:e0)                                   index
                         2=00000000(:e0)
vcpu: 003e pf  pc=0 pfa=0 err=80000007 state=2f task=D:44                     34
vcpu: 003e ret pc=c4c0 sp=bf66bef0 state=2f task=D:44                         33
vcpu: 003e pf  pc=c4c0 pfa=c4c0 err=80000005 state=2f task=D:44               32
vcpu: 003e ret pc=c4c0 sp=bf66bef0 state=27 task=D:44                         31
vcpu: 003e ret pc=209fa20 sp=5c27e88 state=5 task=D:34                        30
vcpu: 003e ipc from D:41 task=D:5 sp=5c27e88                                  29
vcpu: 003e ret pc=2157a94 sp=5c27d1c state=5 task=D:34                        28
[…]

>Now why. I tried my parallella and it works fine for me. What's your hardware?

I am using the ZedBoard from Digilent.

>On the key issue, you have the -serial_esc option too?

On the key issue with Qemu I have tried both with and without the line “kernel fiasco -serial_esc” in the module list with the same result:

modaddr 0x01100000
default-kernel fiasco -serial_esc
default-bootstrap bootstrap
[…]
entry L4Linux ARM
kernel fiasco -serial_esc
roottask moe rom/l4lx.cfg
module l4re
module ned
module l4lx.cfg
module io
module arm-rv.io
module vmlinuz.arm
module ramdisk-arm.rd

>For some debugging, you could add a printf to Vkey::trigger() in src/kern/vkey.cpp and see if it prints or not.

Something strange happened! I wanted to try if the condition was well done with the “vkey_irq”.
So I tried this code:

Vkey::trigger()
{
  //for(int i = 0; i < 10000000; i++);
  if (vkey_irq){
    printf("%x", vkey_irq);
    vkey_irq->hit(0);}  
}

And I can enter into the consol with inputs :-) ! 

Please press Enter to activate this console. f11c8320
/ # f11c8320
/ # f11c8320
/ #

So I tried a few things:
	-	I tried the active loop above for the temporization’s test and I have no inputs: is it an io problem? 
	-	So I tried a blank printf(“”) before the writing of the hit to check syscall and still no input. 
	-	Finally I tried a printf with a space before the writing of the hit (printf(“  ”)) and I have inputs with the space.

So it seems to be an input format problem.

Thanks in advance for your help,

Nicolas

-----Message d'origine-----
De : l4-hackers [mailto:[email protected]] De la part de Adam Lackorzynski
Envoyé : dimanche 22 mars 2015 23:14
À : [email protected]
Objet : Re: ARM with Qemu

Hi,

On Fri Mar 20, 2015 at 11:27:47 +0100, Nicolas VARONA wrote:
> >Ok. Lets look deeper. [...] What do we see?
> 
> I have done the test on both the board and Qemu.
> On Qemu, I can see those lines:
> 
> vcpu: 003e exc #11 err=44000000 pc=132cd8 sp=bfbb9c88 state=2f task         1781

Ok, a syscall, fine.

> On the Board I have those:
> 
> vcpu: 003e pf  pc=fb86c pfa=bf5b3030 err=90000007 state=2f task=D:4           30

A page-fault above the current stack, so that will probably be the cause
for the segfault. Does this always happen in this way?

> vcpu: 003e ret pc=fb850 sp=bf5b2ee8 state=2f task=D:44                        29

Now why. I tried my parallella and it works fine for me. What's your
hardware?

> [...]
> 
> >Hmm, maybe lets first look at the segfault, maybe it's related but probably not.
> 
> It's strange because all seem to be well enabled and I have the same segfault. I give you the output with the configuration file we tested last time:

On the key issue, you have the -serial_esc option too?
For some debugging, you could add a printf to Vkey::trigger() in
src/kern/vkey.cpp and see if it prints or not.




Adam
-- 
Adam                 [email protected]
  Lackorzynski         http://os.inf.tu-dresden.de/~adam/

_______________________________________________
l4-hackers mailing list
[email protected]
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
_______________________________________________
l4-hackers mailing list
[email protected]
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers