Re: [Xen-users] Issues Booting DomU on TI DRA72 Chip

[Brandon Perez <a0225893@xxxxxx>]

On 07/07/2015 03:30 PM, Brandon Perez wrote:
> On 07/07/2015 09:35 AM, Brandon Perez wrote:
> > On 07/07/2015 09:53 AM, Julien Grall wrote:
> > > Hi,
> > >
> > > On 06/07/15 18:21, Brandon Perez wrote:
> > > > On 07/03/2015 06:30 AM, Julien Grall wrote:
> > > > > Hi,
> > > > >
> > > > > On 02/07/15 17:04, Brandon Perez wrote:
> > > > > > (d1) 6xen:grant_table: Grant tables using version 1 layout
> > > > > > (d1) Grant table initialized
> > > > > > (d1) 6xen:events: Using FIFO-based ABI
> > > > > > (d1) 6Xen: initializing cpu0
> > > > > > (d1) 6Setting up static identity map for 0x405f7c28 - 0x405f7c80
> > > > > It's hard to know what's going on with only these 5 lines. Is it the
> > > > > full log of the domU? If not, can you send it?
> > > > >
> > > > > Usually, the next step is to bring up the other processor, although
> > > > > you
> > > > > have only 1 vCPU in the device tree.
> > > > >
> > > > > Regards,
> > > > Hi Julien,
> > > >
> > > >      Unfortunately, that is the full log of the domU messages that I
> > > > get
> > > > from "xl dmesg". That's part of the reason why I'm having a hard time
> > > > tracking down this issue, because I'm getting so little information
> > > > back
> > > > from the guest.
> > > >
> > > >     There's also the domU.log file that I attached in the prior email
> > > > that has additional information.
> > > >
> > > >     Do you have any advice what might be causing this issue just
> > > > based on
> > > > that information?
> > > Not really. Can you try patch in [0]? It should print more on the
> > > console compare to the one you applied from [1].
> > >
> > > You may also want to add ignore_loglevel on kernel guest command line.
> > >
> > > Regards,
> > >
> > > [0] https://patches.linaro.org/39687/
> > > [1]
> > > http://xenbits.xen.org/gitweb/?p=people/ianc/linux.git;a=commitdiff;h=476bff35f03de10392826672cfd0d9e2c40ea7eb
> > Hi Julien,
> >
> >     I added applied patch [0], and I've attached the logging output that
> > I got with that patch. Nothing in the log really jumps out at me, and
> > the kernel seems to be booting fine until it freezes up for some reason.
> >
> >     Is it possible that I'm not setting up the DomU's filesystem
> > correctly? I'm currently using a 800 Mb image on the Dom0 filesystem
> > that's formatted as ext3. Do I need to mount this somewhere on Dom0's
> > filesystem before running "xl create"? I could see this as a potential
> > reason for the guest domain to freeze up.
> >
> > Brandon
>     I've done some digging to figuring out exactly where the domU kernel
> is getting stuck during boot. It's happening during a pre-SMP init call,
> specifically spawn_ksoftirqd(). The boot is getting stuck specifically
> in the function smpboot_unpark_thread().
>
> The backtrace of this is (these are all 3.14 kernel files):
>      smpboot_unpark_thread(): kernel/smpboot.c: 218
>      smpboot_register_percpu_thread(): kernel/smpboot.c: 289
>      spawn_ksoftirqd(): kernel/softirq.c: 756
>      do_one_initcall(): init/main.c: 704
>      do_pre_smp_initcalls(): init/main.c: 806
>      kernel_init_freeable(): init/main.c: 915
>
> I was wondering if this is an issue that you guys may have seen before.
> If not, do you have any advice? It seems to be related somehow to
> scheduling and/or acquiring locks related to that.
>
> Brandon
    I've done some additional digging to figure out exactly where the 
code is getting stuck. The kernel is getting stuck while waiting to be 
woken up from an hrtimer, which it uses to sleep for a period of time.
    My guess is either this must be related to how threads are being 
scheduled on the CPU, or it must be resulting from the timer IRQ not 
being delivered to the guest domain.
Here's the full backtrace:
    schedule(): kernel/sched/core.c: 2769
    schedule_hrtimeout_range_clock(): kernel/hrtimer.c: 1857
    schedule_hrtimeout_range(): kernel/hrtimer.c: 1898
    schedule_hrtimeout(): kernel/hrtimer.c: 1928
    wait_task_inactive(): kernel/sched/core.c: 1230
    __kthread_bind(): kernel/kthread.c: 333
    __kthread_unpark(): kernel/kthread.c: 397
    kthread_unpark(): kernel/kthread.c: 422
    smpboot_unpark_thread(): kernel/smpboot.c: 226
    smpboot_register_percpu_thread(): kernel/smpboot.c: 289
    spawn_ksoftirqd(): kernel/softirq.c: 756
    do_one_initcall(): init/main.c: 704
    do_pre_smp_initcalls(): init/main.c: 806
    kernel_init_freeable(): init/main.c: 915

   Have you guys seen an issue similar to this before? Or do you have 
any advice based on where the DomU kernel is getting stuck?
Brandon

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