Re: [Xen-devel] Running Xen on Nvidia Jetson-TK1

[Dushyant Behl <myselfdushyantbehl@xxxxxxxxx>]

Hi Everyone,

On Mon, Mar 21, 2016 at 3:42 PM, Dushyant Behl
<myselfdushyantbehl@xxxxxxxxx> wrote:
> Hi Julien,
>
> On Fri, Mar 18, 2016 at 10:53 PM, Julien Grall <julien.grall@xxxxxxx> wrote:
>>
>>
>> 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@xxxxxxx>
>>> 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).
>
> I have blacklisted the tegra20_timer and now dom0 is able to pass that
> step but now the dom0 kernel gets stuck in an infinite loop in the
> function calibrate_delay_converge.
>
> This is the call stack -
>  -  calibrate_delay_converge
>  -  calibrate_delay
>  -  start_kernel
>
> Right now I'm not sure about the exact point where it is going into
> the infinite loop.

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 -

(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?

Thanks,
Dushyant

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