Re: [Xen-devel] Domain 0 crashed when booting OMAP5 uEVM

[Chen Baozi <baozich@xxxxxxxxx>]

On Aug 15, 2013, at 6:07 PM, Julien Grall <julien.grall@xxxxxxxxxx> wrote:

> On 15 August 2013 10:47, Chen Baozi <baozich@xxxxxxxxx> wrote:
>> On Thu, Aug 15, 2013 at 10:13:15AM +0100, Julien Grall wrote:
>>> On 14 August 2013 13:38, Chen Baozi <baozich@xxxxxxxxx> wrote:
>>>> 
>>>> On Aug 14, 2013, at 5:55 PM, Julien Grall <julien.grall@xxxxxxxxxx> wrote:
>>>> 
>>>>> On 14 August 2013 10:46, Chen Baozi <baozich@xxxxxxxxx> wrote:
>>>>>> 
>>>>>> On Aug 13, 2013, at 5:58 PM, Julien Grall <julien.grall@xxxxxxxxxx> 
>>>>>> wrote:
>>>>>> 
>>>>>>> On 13 August 2013 10:36, Andrii Anisov <andrii.anisov@xxxxxxxxxxxxxxx> 
>>>>>>> wrote:
>>>>>>>> disable printings from LK decompressor (it writes directly to omap 
>>>>>>>> debug
>>>>>>>> UART3, and if you give it to xen and don't map to Dom0 - will have data
>>>>>>>> abort)
>>>>>>> 
>>>>>>> With Chen's patch series and the latest Xen, you don't need to disable
>>>>>>> LK decompressor.
>>>>>>> Xen has a basic emulation for "stolen" UART.
>>>>>> 
>>>>>> BTW, does it mean that we don't need to set the UART status "disabled" 
>>>>>> in DTS?
>>>>> 
>>>>> Unfortunately, no. The UART emulation is too simple to handle the real 
>>>>> driver.
>>>>> I'm currently preparing a patch series which will remove this hack in the 
>>>>> DTS.
>>>> 
>>>> Another question.
>>>> 
>>>> Before I saw Linux booting message, there is a line of message:
>>>> 
>>>> (XEN) vgic.c:435:d0 vGICD: GICD_SGIR write r=fe0000 vcpu_mask=fe, wrong 
>>>> CPUTargetList
>>>> 
>>>> Is it a big issue for booting dom0?
>>> 
>>> I don't think so. Linux is trying to send an SGI to a non-running VCPU.
>>> 
>>> I'm curious to know why Linux is trying to do this. Can you try to
>>> apply the patch below and paste dom0 output log?
>>> 
>> 
>> FYI,
>> 
>> [    1.139260] CPU: Testing write buffer coherency: ok
>> [    1.140167] /cpus/cpu@0 missing clock-frequency property
>> [    1.140181] /cpus/cpu@1 missing clock-frequency property
>> [    1.140214] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
>> [    1.140245] Setting up static identity map for 0xc0511478 - 0xc05114d0
>> [    1.143730] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.11.0-rc3+ #19
>> [    1.143766] [<c001b5ec>] (unwind_backtrace+0x0/0xf8) from [<c0017b90>] 
>> (show_stack+0x1)
>> [    1.143786] [<c0017b90>] (show_stack+0x10/0x14) from [<c0506940>] 
>> (dump_stack+0x70/0x8)
>> [    1.143806] [<c0506940>] (dump_stack+0x70/0x8c) from [<c02bca50>] 
>> (gic_raise_softirq+0)
>> [    1.143823] [<c02bca50>] (gic_raise_softirq+0x64/0x70) from [<c00192f8>] 
>> (arch_send_wa)
>> [    1.143844] [<c00192f8>] (arch_send_wakeup_ipi_mask+0x18/0x1c) from 
>> [<c002e6ec>] (omap)
>> [    1.143860] [<c002e6ec>] (omap4_boot_secondary+0xf4/0x174) from 
>> [<c0018f78>] (__cpu_up)
>> [    1.143877] [<c0018f78>] (__cpu_up+0x84/0x130) from [<c004408c>] 
>> (_cpu_up+0xd4/0x154)
>> [    1.143894] [<c004408c>] (_cpu_up+0xd4/0x154) from [<c0044184>] 
>> (cpu_up+0x5c/0x84)
>> [    1.143916] [<c0044184>] (cpu_up+0x5c/0x84) from [<c0740ba4>] 
>> (smp_init+0x9c/0xd4)
>> [    1.143935] [<c0740ba4>] (smp_init+0x9c/0xd4) from [<c072789c>] 
>> (kernel_init_freeable+)
>> [    1.143954] [<c072789c>] (kernel_init_freeable+0x70/0x1c4) from 
>> [<c0501d2c>] (kernel_i)
>> [    1.143972] [<c0501d2c>] (kernel_init+0x8/0xe4) from [<c0013f48>] 
>> (ret_from_fork+0x14/)
>> [    2.152167] CPU1: failed to come online
>> [    2.152516] Brought up 1 CPUs
>> [    2.152527] SMP: Total of 1 processors activated (12.28 BogoMIPS).
>> [    2.152535] CPU: All CPU(s) started in SVC mode.
> 
> Xen uses PSCI to bring up secondary VCPU. It seems Linux is trying to
> bring up the CPU with omap callbacks which is wrong.
> 
> Did you add a PSCI node in your device tree?
> psci {
>      compatible      = "arm,psci";
>      method          = "hvc";
>      cpu_on          = <2>;
> };

Oops, that is the point. I didn't add it. And it would be OK after adding.

Thanks.

Baozi
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel