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

[Julien Grall <julien.grall@xxxxxxxxxx>]

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?

============================================================
diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
index ee7c503..73161cc 100644
--- a/drivers/irqchip/irq-gic.c
+++ b/drivers/irqchip/irq-gic.c
@@ -652,6 +652,9 @@ void gic_raise_softirq(const struct cpumask *mask,
unsigned int irq)
  for_each_cpu(cpu, mask)
  map |= gic_cpu_map[cpu];

+    if ( map == 0xfe )
+        dump_stack();
+
  /*
  * Ensure that stores to Normal memory are visible to the
  * other CPUs before issuing the IPI.
============================================================

-- 
Julien Grall

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