| Message ID | 56EAC498.1030400@arm.com |
|---|---|
| State | New |
| Headers | show |
On 18/03/16 15:01, Dushyant Behl wrote: > Hi Julien, Hi Dushyant, > On Thu, Mar 17, 2016 at 8:22 PM, Julien Grall <julien.grall@arm.com> wrote: >> On 14/03/16 14:19, Dushyant Behl wrote: >>>> Yes, I have enabled these configuration parameters when compiling linux - >> >> The list of options looks good to me. I guess Linux is crashing before setting >> up the console. Can you apply the below to Linux and post the log here? > > I applied your patch to Linux but still there is no output from the kernel. > > But I have found location of the problem, I have a debugger attached > to the Jetson board > and using that I was able to find out that Linux is failing while > initializing the Tegra timer. > > The call stack at the time of failing is - > > - prefetchw (inline) > arch_spin_lock (inline) > do_raw_spin_lock_flags (inline) > __raw_spin_lock_irqssave (inline) > raw_spin_lock_irq_save (lock = 0xC0B746F0) > - of_get_parent (node = 0xA00001D3) > - of_get_address (dev = 0xDBBABC30, index = 0, size = 0xC0A83F30) > - of_address_to_resource(dev = 0xDBBABC30, index = 0, r = 0xC0A83F50) > - of_iomap (np = 0xDBBABC30, index = 0) > - tegra20_init_timer (np = 0xDBBABC30) > - clocksource_of_init() > - start_kernel() > > After this Linux jumps to floating point exception handler and then to > undefined instruction and fails. I don't know why Linux is receiving a floating point exception. However, DOM0 must not use the tegra timer as it doesn't support virtualization. You need to ensure that DOM0 will use the arch timer instead. Xen provides some facilities to blacklist a device tree node (see blacklist dev in arm/platforms/tegra.c). Regards,
Hello Dushyant, On 24/03/16 11:05, Dushyant Behl wrote: > I was not receiving the dom0 logs because of a mistake in my dom0 > bootargs. In the bootargs the option > for earlyprintk was not marked as Xen. Now that I've enabled it I'm > able to see some bootlog from dom0 linux. > > At least now I'm able to figure out the reason of Linux running into > infinite loop. > > It seems like Linux is not receiving any interrupts from the arch > timer and when it tries > to calibrate the timer delay then there's a loop where linux waits to > receive ticks to calculate > loops_per_jiffies and that's the point where dom0 is running into the > infinite loop. > (exact point is http://osxr.org:8080/linux/source/init/calibrate.c#0196) > > This is the dom0 bootlog which I received after correcting the > earlyprintk argument - Can you provide the full log? So we can see if there is anything which could give us a hint about your problem. > > (XEN) DOM0: Uncompressing Linux... done, booting the kernel. > (XEN) DOM0: [ 0.000000] Booting Linux on physical CPU 0x0 > (XEN) DOM0: [ 0.000000] Initializing cgroup subsys cpu > (XEN) DOM0: [ 0.000000] Initializing cgroup subsys cpuacct > (XEN) DOM0: [ 0.000000] Linux version > 4.1.0-196898-g2e68ed9-dirty(root@ubuntu-server) (gcc version 4.7.3 > (Ubuntu/Linaro 4.7.3-11ubuntu > (XEN) DOM0: 1) ) #12 SMP PREEMPT Thu Mar 24 09:56:36 UTC 2016 > (XEN) DOM0: [ 0.000000] CPU: ARMv7 Processor [413fc0f3] revision 3 > (ARMv7), cr=30c5387d > (XEN) DOM0: [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, > PIPT instruction cache > (XEN) DOM0: [ 0.000000] Machine model: NVIDIA Tegra124 Jetson TK1 > (XEN) DOM0: [ 0.000000] bootconsole [earlycon0] enabled > (XEN) DOM0: [ 0.000000] cma: Reserved 64 MiB at 0x00000000bc000000 > (XEN) DOM0: [ 0.000000] Forcing write-allocate cache policy for SMP > (XEN) DOM0: [ 0.000000] Memory policy: Data cache writealloc > (XEN) DOM0: [ 0.000000] psci: probing for conduit method from DT. > (XEN) DOM0: [ 0.000000] psci: PSCIv0.2 detected in firmware. > (XEN) DOM0: [ 0.000000] psci: Using standard PSCI v0.2 function IDs > (XEN) DOM0: [ 0.000000] PERCPU: Embedded 12 pages/cpu @dbb77000 > s19712 r8192 d21248 u49152 > (XEN) DOM0: [ 0.000000] Built 1 zonelists in Zone order, mobility > grouping on. Total pages: 130048 > (XEN) DOM0: [ 0.000000] Kernel command line: console=hvc0 > console=tty1 earlyprintk=xen root=/dev/mmcblk0p1 rw rootwait > tegraid=40.1.1.0.0 > (XEN) DOM0: [ 0.000000] PID hash table entries: 2048 (order: 1, 8192 bytes) > (XEN) DOM0: [ 0.000000] Dentry cache hash table entries: 65536 > (order: 6, 262144 bytes) > (XEN) DOM0: [ 0.000000] Inode-cache hash table entries: 32768 > (order: 5, 131072 bytes) > (XEN) DOM0: [ 0.000000] Memory: 441884K/524288K available (7657K > kernel code, 634K rwdata, 2584K rodata, 484K init, 383K bss, 16868K > reserved, 65536K cma-reserved, 0K highmem) > (XEN) DOM0: [ 0.000000] Virtual kernel memory layout: > (XEN) DOM0: [ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB) > (XEN) DOM0: [ 0.000000] fixmap : 0xffc00000 - 0xfff00000 (3072 kB) > (XEN) DOM0: [ 0.000000] vmalloc : 0xe0800000 - 0xff000000 ( 488 MB) > (XEN) DOM0: [ 0.000000] lowmem : 0xc0000000 - 0xe0000000 ( 512 MB) > (XEN) DOM0: [ 0.000000] pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB) > (XEN) DOM0: [ 0.000000] modules : 0xbf000000 - 0xbfe00000 ( 14 MB) > (XEN) DOM0: [ 0.000000] .text : 0xc0008000 - 0xc0a08c10 (10244 kB) > (XEN) DOM0: [ 0.000000] .init : 0xc0a09000 - 0xc0a82000 ( 484 kB) > (XEN) DOM0: [ 0.000000] .data : 0xc0a82000 - 0xc0b20bec ( 635 kB) > (XEN) DOM0: [ 0.000000] .bss : 0xc0b23000 - 0xc0b82ea0 ( 384 kB) > (XEN) DOM0: [ 0.000000] Preemptible hierarchical RCU implementation. > (XEN) DOM0: [ 0.000000] Build-time adjustment of leaf fanout to 32. > (XEN) DOM0: [ 0.000000] NR_IRQS:16 nr_irqs:16 16 > (XEN) DOM0: [ 0.000000] of_irq_init: children remain, but no parents > (XEN) DOM0: [ 0.000000] L2C: failed to init: -19 > (XEN) DOM0: [ 0.000000] irq: no irq domain found for /interrupt-controller ! > (XEN) DOM0: [ 0.000000] irq: no irq domain found for /interrupt-controller ! > (XEN) DOM0: [ 0.000000] irq: no irq domain found for /interrupt-controller ! > (XEN) DOM0: [ 0.000000] arch_timer: No interrupt available, giving up > (XEN) DOM0: [ 0.000000] sched_clock: 32 bits at 100 Hz, resolution > 10000000ns, wraps every 21474836475000000ns > (XEN) DOM0: [ 0.000000] Console: colour dummy device 80x30 > (XEN) DOM0: [ 0.000000] console [tty1] enabled > > Can anyone explain why Linux is not able to get any interrupts from > the arch timer? > Is this some problem with Xen's interrupt mappings or some issue with > the dom0 kernel? From the log: "arch_timer: No interrupt available, giving up". So the kernel is not able to get the interrupt from device tree. Which device-tree are you using for the board? Regards,
Hello Dushyant, On 29/03/16 21:56, Dushyant Behl wrote: > On Wed, Mar 30, 2016 at 12:31 AM, Julien Grall <julien.grall@arm.com> wrote: >> On 24/03/16 11:05, Dushyant Behl wrote: > (XEN) DOM0: [ 0.000000] irq: no irq domain found for /interrupt-controller ! > (XEN) DOM0: [ 0.000000] irq: no irq domain found for /interrupt-controller ! > (XEN) DOM0: [ 0.000000] irq: no irq domain found for /interrupt-controller ! > (XEN) DOM0: [ 0.000000] arch_timer: No interrupt available, giving up It looks like to me that Xen is not recreating the device-tree correctly. I would look into the kernel to find what is expected. Regards,
On 07/04/16 08:48, Dushyant Behl wrote: > Hello, Hi Dushyant, > On Fri, Apr 1, 2016 at 3:34 PM, Julien Grall <julien.grall@arm.com> wrote: >> Hello Dushyant, >> >> On 29/03/16 21:56, Dushyant Behl wrote: >>> >>> On Wed, Mar 30, 2016 at 12:31 AM, Julien Grall <julien.grall@arm.com> >>> wrote: >>>> >>>> On 24/03/16 11:05, Dushyant Behl wrote: >> >> >>> (XEN) DOM0: [ 0.000000] irq: no irq domain found for >>> /interrupt-controller ! >>> (XEN) DOM0: [ 0.000000] irq: no irq domain found for >>> /interrupt-controller ! >>> (XEN) DOM0: [ 0.000000] irq: no irq domain found for >>> /interrupt-controller ! >>> (XEN) DOM0: [ 0.000000] arch_timer: No interrupt available, giving up >> >> >> It looks like to me that Xen is not recreating the device-tree correctly. I >> would look into the kernel to find what is expected. > > This looks like a possible bug (or some missing feature) in Xen's > device tree creation which could > take some time to handle, so if I could be of any more help to you > with this issue please let me know. There was a conversation on #xen-arm few days ago about this problem. Xen doesn't correctly recreate the GIC node which result in a loop between the interrupt controller. Can you try the below patch? http://dev.ktemkin.com/misc/xenarm-gic-parents.patch > > [I've cc'ed Ian Campbell in this mail (Sorry for cc'ing you explicitly)] Ian's citrix e-mail is not valid anymore. I have CC'ed the new one. > Ian, > > Actually, I want to run Xen on the Tegra Jetson board for some project > of mine but currently Linux-4.1 is > failing as dom0 because its not able to receive interrupts from the arch_timer. > This link contains the dom0 failure boot log - > http://lists.xenproject.org/archives/html/xen-devel/2016-03/msg03715.html > > In your patch for *Hacky* support for Jetsok-TK1 you said that you > were able to run guests on > Jetson-tk1 board with Xen. Can I know which kernel version you used as > dom0 (and possibly domU guests)? Regards,
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c index c963ba5..6f3b85b 100644 --- a/kernel/printk/printk.c +++ b/kernel/printk/printk.c @@ -1657,6 +1657,8 @@ static size_t cont_print_text(char *text, size_t size) return textlen; } +#include <xen/hvc-console.h> + asmlinkage int vprintk_emit(int facility, int level, const char *dict, size_t dictlen, const char *fmt, va_list args) @@ -1724,6 +1726,7 @@ asmlinkage int vprintk_emit(int facility, int level, * prefix which might be passed-in as a parameter. */ text_len = vscnprintf(text, sizeof(textbuf), fmt, args); + xen_raw_console_write(text); /* mark and strip a trailing newline */ if (text_len && text[text_len-1] == '\n') {
Hi Dushyant, On 14/03/16 14:19, Dushyant Behl wrote: > > Yes, I have enabled these configuration parameters when compiling linux - The list of options looks good to me. I guess Linux is crashing before setting up the console. Can you apply the below to Linux and post the log here? Regards,