Re: [Xen-devel] [XenARM] Kernel Panic in booting domU

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Wed, 2013-04-24 at 10:12 +0100, Khandelwal, Shubham wrote:
> I am running xen 4.3.3-unstable on ARM Fast Model for Versatile
> Express platform.

The right list for Xen on ARM with virtualization extensions[0] is
xen-devel@. The xen-arm@ list is for the Xen ARM PV port[1] (for ARMv6
and earlier). I've moved xen-arm to bcc and added xen-devel to cc. (I've
left quotes mostly untrimmed for the benefit of xen-devel)

Xen 4.3 has not been released and "4.3.3-unstable" isn't a real version
and doesn't contain enough information to determine what you are
running. When running development versions a reference to the git commit
ID (and if necessary the tree+branch containing it) is usually better.

[0] http://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions
[1] http://wiki.xen.org/wiki/Xen_ARM_%28PV%29

>  I am getting a kernel panic when I am trying to create a domU using
> âxl createâ command. My linux kernel version for dom0 and domU is
> 3.9.0-rc7. The error is :
> ...
> 
> (XEN) DOM1: Booting Linux on physical CPU 0x0
> (XEN) DOM1: Linux version 3.9.0-rc7 (phoenix@ubuntu) (gcc version 4.6.3 (GCC) 
> ) #8 Tue Apr 23 17:35:45 IST 2013
> (XEN) DOM1: CPU: ARMv7 Processor [412fc0f0] revision 0 (ARMv7), cr=10c53c7d
> (XEN) DOM1: CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
> (XEN) DOM1: Machine: ARM-Versatile Express, model: XENVM-4.2
> (XEN) DOM1: bootconsole [earlycon0] enabled
> (XEN) DOM1: Memory policy: ECC disabled, Data cache writeback
> (XEN) DOM1: On node 0 totalpages: 32768
> (XEN) DOM1: free_area_init_node: node 0, pgdat c0479040, node_mem_map c049c000
> (XEN) DOM1:   Normal zone: 256 pages used for memmap
> (XEN) DOM1:   Normal zone: 0 pages reserved
> (XEN) DOM1:   Normal zone: 32768 pages, LIFO batch:7
> (XEN) DOM1: CPU: All CPU(s) started in SVC mode.
> (XEN) DOM1: pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
> (XEN) DOM1: pcpu-alloc: [0] 0
> (XEN) DOM1: Built 1 zonelists in Zone order, mobility grouping on.  Total 
> pages: 32512
> (XEN) DOM1: Kernel command line: earlyprintk=xenboot console=hvc0 
> root=/dev/xvda debug rw init=/bin/sh
> (XEN) DOM1: PID hash table entries: 512 (order: -1, 2048 bytes)
> (XEN) DOM1: Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
> (XEN) DOM1: Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
> (XEN) DOM1: __ex_table already sorted, skipping sort
> (XEN) DOM1: Memory: 128MB = 128MB total
> (XEN) DOM1: Memory: 125180k/125180k available, 5892k reserved, 0K highmem
> (XEN) DOM1: Virtual kernel memory layout:
> (XEN) DOM1:     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
> (XEN) DOM1:     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
> (XEN) DOM1:     vmalloc : 0xc8800000 - 0xff000000   ( 872 MB)
> (XEN) DOM1:     lowmem  : 0xc0000000 - 0xc8000000   ( 128 MB)
> (XEN) DOM1:     pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
> (XEN) DOM1:       .text : 0xc0008000 - 0xc042e138   (4249 kB)
> (XEN) DOM1:       .init : 0xc042f000 - 0xc0450d34   ( 136 kB)
> (XEN) DOM1:       .data : 0xc0452000 - 0xc04799c0   ( 159 kB)
> (XEN) DOM1:        .bss : 0xc04799c0 - 0xc049b62c   ( 136 kB)
> (XEN) DOM1: NR_IRQS:16 nr_irqs:16 16
> (XEN) DOM1: ------------[ cut here ]------------
> (XEN) DOM1: WARNING: at drivers/clk/versatile/clk-vexpress.c:29 
> vexpress_sp810_init+0xa0/0xcc()
> (XEN) DOM1: [<c0011b24>] (unwind_backtrace+0x0/0xe0) from [<c00184f8>] 
> (warn_slowpath_common+0x48/0x64)
> (XEN) DOM1: [<c00184f8>] (warn_slowpath_common+0x48/0x64) from [<c00185cc>] 
> (warn_slowpath_null+0x18/0x1c)
> (XEN) DOM1: [<c00185cc>] (warn_slowpath_null+0x18/0x1c) from [<c04436a8>] 
> (vexpress_sp810_init+0xa0/0xcc)
> (XEN) DOM1: [<c04436a8>] (vexpress_sp810_init+0xa0/0xcc) from [<c04438cc>] 
> (vexpress_clk_of_init+0x2c/0x140)
> (XEN) DOM1: [<c04438cc>] (vexpress_clk_of_init+0x2c/0x140) from [<c0435a78>] 
> (v2m_dt_timer_init+0x8/0x90)
> (XEN) DOM1: [<c0435a78>] (v2m_dt_timer_init+0x8/0x90) from [<c0432ed4>] 
> (time_init+0x14/0x20)
> (XEN) DOM1: [<c0432ed4>] (time_init+0x14/0x20) from [<c042f610>] 
> (start_kernel+0x184/0x2bc)
> (XEN) DOM1: [<c042f610>] (start_kernel+0x184/0x2bc) from [<80008070>] 
> (0x80008070)
> (XEN) DOM1: ---[ end trace 1b75b31a2719ed1c ]---
> (XEN) DOM1: ------------[ cut here ]------------
> (XEN) DOM1: WARNING: at drivers/clk/versatile/clk-vexpress.c:116 
> vexpress_clk_of_init+0x78/0x140()
> (XEN) DOM1: [<c0011b24>] (unwind_backtrace+0x0/0xe0) from [<c00184f8>] 
> (warn_slowpath_common+0x48/0x64)
> (XEN) DOM1: [<c00184f8>] (warn_slowpath_common+0x48/0x64) from [<c00185cc>] 
> (warn_slowpath_null+0x18/0x1c)
> (XEN) DOM1: [<c00185cc>] (warn_slowpath_null+0x18/0x1c) from [<c0443918>] 
> (vexpress_clk_of_init+0x78/0x140)
> (XEN) DOM1: [<c0443918>] (vexpress_clk_of_init+0x78/0x140) from [<c0435a78>] 
> (v2m_dt_timer_init+0x8/0x90)
> (XEN) DOM1: [<c0435a78>] (v2m_dt_timer_init+0x8/0x90) from [<c0432ed4>] 
> (time_init+0x14/0x20)
> (XEN) DOM1: [<c0432ed4>] (time_init+0x14/0x20) from [<c042f610>] 
> (start_kernel+0x184/0x2bc)
> (XEN) DOM1: [<c042f610>] (start_kernel+0x184/0x2bc) from [<80008070>] 
> (0x80008070)
> (XEN) DOM1: ---[ end trace 1b75b31a2719ed1d ]---
> (XEN) DOM1: sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 
> 178956ms
> (XEN) DOM1: Unable to handle kernel NULL pointer dereference at virtual 
> address 0000005c
> (XEN) DOM1: pgd = c0004000
> (XEN) DOM1: [0000005c] *pgd=00000000
> (XEN) DOM1: Internal error: Oops: 5 [#1] ARM
> (XEN) DOM1: CPU: 0    Tainted: G        W     (3.9.0-rc7 #8)
> (XEN) DOM1: PC is at versatile_read_sched_clock+0x10/0x28

This should never be being called in a domU AFAICT.

What device tree are you passing/appending to the domU kernel?

This function should only be called if arch_timer_sched_clock_init()
failed for some reason, which looks like it can only happen if
arch_timer_get_rate() returns 0, which in turn only happens if
arch_timer_available == 0.

Which all suggests that arch_timer_of_register() must have failed,
however I don't see an error path which doesn't log and I don't see
anything in your logs.

Perhaps you could instrument up that callchain and see what's going on?

Stefano's patches to switch to using mach-virt instead of mach-vexpress
probably side step this issue too.

> (XEN) DOM1: LR is at update_sched_clock+0x14/0x68
> (XEN) DOM1: pc : [<c001633c>]    lr : [<c000f85c>]    psr: 200001d3
> (XEN) DOM1: sp : c0453f68  ip : 000008d8  fp : 0000001a
> (XEN) DOM1: r10: 0000004d  r9 : 00000000  r8 : 00000018
> (XEN) DOM1: r7 : a6aaaaab  r6 : c045a010  r5 : 0002bb0c  r4 : c045d210
> (XEN) DOM1: r3 : 0000005c  r2 : 00003eeb  r1 : 00000028  r0 : 00003eeb
> (XEN) DOM1: Flags: nzCv  IRQs off  FIQs off  Mode SVC_32  ISA ARM  Segment 
> kernel
> (XEN) DOM1: Control: 10c53c7d  Table: 80004059  DAC: 00000015
> (XEN) DOM1: Process swapper (pid: 0, stack limit = 0xc0452230)
> (XEN) DOM1: Stack: (0xc0453f68 to 0xc0454000)
> (XEN) DOM1: 3f60:                   aaaaaa96 0002bb0c c045d210 c0432484 
> 00000029 00000000
> (XEN) DOM1: 3f80: 0002bb0c c03ca210 00000000 00000020 aaaaaa96 00000029 
> c03ca214 c04799c0
> (XEN) DOM1: 3fa0: ffffffff c044ab48 c059cb40 80004059 412fc0f0 00000000 
> 00000000 c0432ed4
> (XEN) DOM1: 3fc0: c0481300 c042f610 ffffffff ffffffff c042f274 00000000 
> 00000000 c044ab48
> (XEN) DOM1: 3fe0: 00000000 10c53c7d c045a02c c044ab44 c045d1a4 80008070 
> 00000000 00000000
> (XEN) DOM1: [<c001633c>] (versatile_read_sched_clock+0x10/0x28) from 
> [<c000f85c>] (update_sched_clock+0x14/0x68)
> (XEN) DOM1: [<c000f85c>] (update_sched_clock+0x14/0x68) from [<c0432484>] 
> (setup_sched_clock+0x1a0/0x1e0)
> (XEN) DOM1: [<c0432484>] (setup_sched_clock+0x1a0/0x1e0) from [<c0432ed4>] 
> (time_init+0x14/0x20)
> (XEN) DOM1: [<c0432ed4>] (time_init+0x14/0x20) from [<c042f610>] 
> (start_kernel+0x184/0x2bc)
> (XEN) DOM1: [<c042f610>] (start_kernel+0x184/0x2bc) from [<80008070>] 
> (0x80008070)
> (XEN) DOM1: Code: e59f301c e5933000 e3530000 0a000002 (e5930000)
> (XEN) DOM1: ---[ end trace 1b75b31a2719ed1e ]---
> (XEN) DOM1: Kernel panic - not syncing: Attempted to kill the idle task!




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