[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

On 07/07/2015 09:35 AM, Brandon Perez wrote:
On 07/07/2015 09:53 AM, Julien Grall wrote:

On 06/07/15 18:21, Brandon Perez wrote:
On 07/03/2015 06:30 AM, Julien Grall wrote:

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.


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.


[0] https://patches.linaro.org/39687/

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.


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.


Xen-users mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.