From mboxrd@z Thu Jan 1 00:00:00 1970 From: Martin Wilck Subject: Re: Re: system freeze when processor.ko is loaded during boot Date: Sun, 03 Apr 2011 15:46:10 +0200 Message-ID: <4D987A22.5050303@arcor.de> References: <4CAF794F.6070308@arcor.de> <4CBEAEE2020000780001E237@vpn.id2.novell.com> <4D910C24.5090908@arcor.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------030900010802050302040607" Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Haitao Shan Cc: "Liu, Jinsong" , "xen-devel@lists.xensource.com" , "Jiang, Yunhong" , Jan Beulich , "Dugger, Donald D" , "Li, Xin" , "Wei, Gang" List-Id: xen-devel@lists.xenproject.org This is a multi-part message in MIME format. --------------030900010802050302040607 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 03/31/2011 08:23 AM, Haitao Shan wrote: > I have checked your dump info via debug key. I saw that the EIPs > remained the same between two successive dump. However, without the > symbols I could not identify which code kernel was hanging on. Is it > possible that you can find this information by disassembling the kernel > binaries (with symbols). I think Jan did just that already, I am attaching his analysis again. > Or could you please repeat your test using an > upstreaming Xen and kernel so that I could compile a same kernel just as > you would be using? Can do that but it needs some time. > And I see you CPU is a very old model, UP without 64 bit support and no > PAE? Right? It has PAE, but it is UP and has no 64bit nor VT-x. processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 13 model name : Intel(R) Pentium(R) M processor 2.13GHz stepping : 8 cpu MHz : 800.000 cache size : 2048 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov clflush dts acpi mmx fxsr sse sse2 ss tm pbe up bts est tm2 bogomips : 1596.45 clflush size : 64 cache_alignment : 64 address sizes : 32 bits physical, 32 bits virtual Martin --------------030900010802050302040607 Content-Type: message/rfc822; name="Attached Message" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Attached Message" Return-Path: X-Original-To: mwilck@arcor.de Received: from mail-in-16.arcor-online.net (mail-in-16.arcor-online.net [151.189.21.56]) by mail-in-20-z2.arcor-online.net (Postfix) with ESMTP id C7716E9925 for ; Thu, 31 Mar 2011 13:47:36 +0200 (CEST) Received: from vpn.id2.novell.com (vpn.id2.novell.com [195.33.99.129]) by mx.arcor.de (Postfix) with ESMTPS id 6F0688A1A for ; Thu, 31 Mar 2011 13:47:36 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.2 mx.arcor.de 6F0688A1A Received: from EMEA1-MTA by vpn.id2.novell.com with Novell_GroupWise; Thu, 31 Mar 2011 12:47:34 +0100 Message-Id: <4D94862E02000078000395D0@vpn.id2.novell.com> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Thu, 31 Mar 2011 12:48:30 +0100 From: "Jan Beulich" To: "Martin Wilck" , "Jinsong Liu" , "xen-devel@lists.xensource.com" Cc: "Donald D Dugger" , "Gang Wei" ,"Xin Li" , "Yunhong Jiang" Subject: Re: [Xen-devel] Re: system freeze when processor.ko is loaded during boot References: <4CAF794F.6070308@arcor.de> <4CBEAEE2020000780001E237@vpn.id2.novell.com> <4D910C24.5090908@arcor.de> <4D911044.8000306@arcor.de> In-Reply-To: <4D911044.8000306@arcor.de> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-DCC-ARCOR-Metrics: mail-in-20-z2 1242; Body=1 Fuz1=1 Fuz2=1 X-Arcor-Antispam: SPF_NONE IN_REPLY_TO LOCALPART_IN_SUBJECT X-ArcorSpamBlocker: Spamcount: 2 Sensitivity: 16 >>> On 29.03.11 at 00:48, Martin Wilck wrote: > Here is one more capture. It shows that (unfortunately) clocksource=3Dpit= > doesn't help here, and that the xen watchdog hits if I configure it > (just that the reboot doesn't work, and I can only see the output since > I've been using the serial console). The stack evaluates to=20 logarithmic_accumulation update_wall_time do_timer(0x898d7) tick_do_update_jiffies64 tick_sched_timer __run_hrtimer hrtimer_interrupt timer_interrupt (matches the previously sent one, just that there the tick count passed to do_timer() is "only" 0x179ab. So the kernel, afaict, is busy recovering from the time jump in Xen. It is clearly also a bad sign that the NMI hit while Dom0 was executing, as that guarantees interrupts aren't disabled (and hence timer interrupts can occur, and timers would not be prevented from running - presumably the time jump suppressed the invocation of, among others, the NMI timer). Jan --------------030900010802050302040607 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --------------030900010802050302040607--