From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: Re: system freeze when processor.ko is loaded during boot Date: Thu, 31 Mar 2011 12:48:30 +0100 Message-ID: <4D94862E02000078000395D0@vpn.id2.novell.com> References: <4CAF794F.6070308@arcor.de> <4CBEAEE2020000780001E237@vpn.id2.novell.com> <4D910C24.5090908@arcor.de> <4D911044.8000306@arcor.de> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <4D911044.8000306@arcor.de> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Martin Wilck , Jinsong Liu , "xen-devel@lists.xensource.com" Cc: Yunhong Jiang , Gang Wei , Donald D Dugger , Xin Li List-Id: xen-devel@lists.xenproject.org >>> 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