On Tue, 2015-07-07 at 16:57 -0400, Brandon Perez wrote:
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.
My bet would be either missing the timer interrupt, or missing
interrupts generally.
Does your platform set the CNTFRQ register in the firmware or does it
use the device-tree clock-frequency node? If it is the latter then
perhaps Julien's patch "xen/arm: Propagate clock-frequency to DOMU if
present in the DT timer node" (commit 59ccb33c40c in the development
branch) would help? Looks like you are using a slightly older version of
the development branch.
Ian.
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
