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

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

>>> On 08.01.18 at 17:07, <martin@xxxxxxxxx> wrote:
> On Mon, 8 Jan 2018, Jan Beulich wrote:
>>>>> 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 ...
> 4.10.0 + 11 patches to make nvidia/vgpu work 
> (https://github.com/xenserver/xen-4.7.pg).
> debug=n because xen's modified debug build process.
>>> (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.
> xen-syms - http://www.uschovna.cz/en/zasilka/UDP5LVE2679CGBIS-4YV/ 

Thanks. Looks to be a race between a timer in the governor and
the CPUs being brought down. In general the governor is supposed
to be disabled in the course of CPUs being brought down, so first
of all I wonder whether you're having some daemon in use which
sends management requests to the CPUfreq driver in Xen. Such a
daemon should of course be disabled by the system shutdown
scripts. Otherwise please try the attached debugging patch -
maybe we can see something from its output.


Attachment: cpufreq-ondemand-crash.patch
Description: Text document

Xen-devel mailing list



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