From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from omzsmtpe03.verizonbusiness.com ([199.249.25.208]) by merlin.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1VfsZh-0008Ns-AX for kexec@lists.infradead.org; Mon, 11 Nov 2013 14:34:46 +0000 From: Don Slutz Message-ID: <5280EAE9.7040008@terremark.com> Date: Mon, 11 Nov 2013 09:34:17 -0500 MIME-Version: 1.0 Subject: Re: [PATCHv10 0/9] Xen: extend kexec hypercall for use with pv-ops kernels References: <1383749386-11891-1-git-send-email-david.vrabel@citrix.com> <20131107211651.GC11159@olila.local.net-space.pl> <20131109191831.GD3439@olila.local.net-space.pl> In-Reply-To: <20131109191831.GD3439@olila.local.net-space.pl> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "kexec" Errors-To: kexec-bounces+dwmw2=twosheds.infradead.org@lists.infradead.org To: Daniel Kiper Cc: kexec@lists.infradead.org, David Vrabel , Jan Beulich , xen-devel@lists.xen.org On 11/09/13 14:18, Daniel Kiper wrote: > On Thu, Nov 07, 2013 at 10:16:51PM +0100, Daniel Kiper wrote: >> On Wed, Nov 06, 2013 at 02:49:37PM +0000, David Vrabel wrote: >>> The series (for Xen 4.4) improves the kexec hypercall by making Xen >>> responsible for loading and relocating the image. This allows kexec >>> to be usable by pv-ops kernels and should allow kexec to be usable >>> from a HVM or PVH privileged domain. >>> >>> I have now tested this with a Linux kernel image using the VGA console >>> which was what was causing problems in v9 (this turned out to be a >>> kexec-tools bug). >>> >>> The required patch series for kexec-tools will be posted shortly and >>> are available from the xen-v7 branch of: >> In general it works. However, quite often I am not able to execute panic >> kernel. Machine hangs with following message: >> >> (XEN) Domain 0 crashed: Executing crash image >> >> gdb shows: >> >> (gdb) bt >> #0 0xffff82d0801a0092 in do_nmi_crash (regs=) at crash.c:113 >> #1 0xffff82d0802281d9 in nmi_crash () at entry.S:666 >> #2 0x0000000000000000 in ?? () >> (gdb) >> >> Especially second bt line scares me... ;-))) >> >> I have not been able to identify why NMI was activated because >> stack is completely cleared. I tried to record execution in gdb >> but it stops with following message: >> >> cpumask_clear_cpu (dstp=0xffff82d0802f7f78 , cpu=0) >> at /srv/dev/xen/xen_20130413_20131107.kexec/xen/include/xen/cpumask.h:108 >> 108 clear_bit(cpumask_check(cpu), dstp->bits); >> Process record: failed to record execution log. >> >> Do you know how to find out why NMI was activated? >> >> I am able almost always reproduce this issue doing this: >> - boot Xen, >> - load panic kernel, >> - echo c > /proc/sysrq-trigger, >> - reboot from command line, >> - boot Xen, >> - load panic kernel, >> - echo c > /proc/sysrq-trigger. > I am not able to reproduce this on real hardware. Sorry for confusion. > > Hence, for whole Xen kexec/kdump series: > > Reviewed-by: Daniel Kiper > Tested-by: Daniel Kiper > > Daniel Also Tested-by: Don Slutz -Don Slutz > _______________________________________________ > kexec mailing list > kexec@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/kexec _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec