Re: [Xen-devel] [BUG] unable to shutdown (page fault in mwait_idle()/do_dbs_timer()/__find_next_bit()) (fwd)

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 07.01.18 at 13:34, <martin@xxxxxxxxx> wrote:
> (XEN) ----[ Xen-4.10.0-vgpu  x86_64  debug=n   Not tainted ]----

The -vgpu tag makes me wonder whether you have any patches in
your tree on top of plain 4.10.0 (or 4.10-staging). Also the debug=n
above ...

> (XEN) CPU:    23
> (XEN) RIP:    e008:[<ffff82d08026ae60>] __find_next_bit+0x10/0x80
> (XEN) RFLAGS: 0000000000010206   CONTEXT: hypervisor
> (XEN) rax: 0000000000000000   rbx: ffff830879db0400   rcx: 0000000000000018
> (XEN) rdx: 0000000000000018   rsi: 0000000000000018   rdi: 0000000000000000
> (XEN) rbp: 00000000061be65c   rsp: ffff83104eaafdd8   r8:  0000000000000018
> (XEN) r9:  ffff830879db6d70   r10: ffff830879db28e8   r11: 0000014161aecbf1
> (XEN) r12: 0000000000000000   r13: ffff8308788cef80   r14: ffff82d0805614e0
> (XEN) r15: 0000000000000017   cr0: 000000008005003b   cr4: 00000000001526e0
> (XEN) cr3: 000000007da2f000   cr2: 0000000000000000
> (XEN) fsb: 0000000000000000   gsb: 0000000000000000   gss: 0000000000000000
> (XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: e008
> (XEN) Xen code around <ffff82d08026ae60> (__find_next_bit+0x10/0x80):
> (XEN)  e1 3f 48 8d 3c c7 74 25 <4c> 8b 0f 41 b8 40 00 00 00 41 29 c8 49 d3 e9 
> 49
> (XEN) Xen stack trace from rsp=ffff83104eaafdd8:
> (XEN)    ffff82d080253180 0000000000000017 ffff830800000018 ffff82d080577380
> (XEN)    00200f0879db6d98 000001415ff7b66d 0000000000000004 ffff830879db6e40
> (XEN)    ffff82d08054ac80 000001415ff7b66d 0000000000000017 0000000000000017
> (XEN)    ffff82d0802c7c0e ffff830879db0300 000001415a01f82d ffff830879db6ef8
> (XEN)    0000002000000008 000012340000152e 0000000000000000 0000000000000000
> (XEN)    0000001900000001 ffff82e028c4b300 ffff82000007ffff ffff82d080552c80
> (XEN)    ffff82d08054b800 ffff82d0805771f0 0000000000000017 0000000000000017
> (XEN)    ffff82d0805614e0 ffff82d080420e80 ffff82d08026fa56 000000fd00000000
> (XEN)    ffff83104eaaffff ffff83007ddf5000 ffff83007ddf5000 ffff83007ddf5000
> (XEN)    ffff830879db0180 ffff830879db0188 000001415a00df4b ffff82d0805614e0
> (XEN)    0000000000000002 0000000000008000 0000000000000004 0000000000000000
> (XEN)    0000000000000000 0000000000000050 0000000000000000 0000000000000000
> (XEN)    0000000000000203 0000000000000000 0000000000002001 0000000000000001
> (XEN)    000000000000b004 000000000000b000 000000000000b000 000000fa00000000
> (XEN)    fffff80002a0910c 0000000000000000 0000000000000002 fffff88002ffb840
> (XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
> (XEN)    0000000000000000 0000000000000017 ffff83007ddf5000 00000037f9839080
> (XEN)    00000000001526e0
> (XEN) Xen call trace:
> (XEN)    [<ffff82d08026ae60>] __find_next_bit+0x10/0x80
> (XEN)    [<ffff82d080253180>] cpufreq_ondemand.c#do_dbs_timer+0x160/0x220
> (XEN)    [<ffff82d0802c7c0e>] mwait-idle.c#mwait_idle+0x23e/0x340
> (XEN)    [<ffff82d08026fa56>] domain.c#idle_loop+0x86/0xc0

... makes this call trace unreliable. But even with a reliable call
trace, analysis of the crash would be helped if you made
available the xen-syms (or xen.efi, depending on how you boot)
somewhere.

Finally, there being (as you say) a 10% probability of the crash -
have you been able to connect its occurrence to anything that
the system was doing prior to the shutdown/reboot attempt?
Actually - is this a problem with shutdown _only_, or also with
reboot?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel