From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH] x86/HPET: mask interrupt while changing affinity Date: Tue, 19 Mar 2013 23:24:12 +0000 Message-ID: <5148F39C.30305@citrix.com> References: <514704C202000078000C64A0@nat28.tlf.novell.com> <1701498510.20130319165336@eikelenboom.it> <514899B102000078000C6D74@nat28.tlf.novell.com> <135661008.20130319234805@eikelenboom.it> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <135661008.20130319234805@eikelenboom.it> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Sander Eikelenboom Cc: "Keir (Xen.org)" , Jan Beulich , xen-devel List-Id: xen-devel@lists.xenproject.org On 19/03/13 22:48, Sander Eikelenboom wrote: > Tuesday, March 19, 2013, 5:00:33 PM, you wrote: > >>>>> On 19.03.13 at 16:53, Sander Eikelenboom wrote: >>> Could this change have a averse affect on AMD systems ? >> It shouldn't, ... >>> With this patch booting the dom0 kernel slowly seems to come to a halt >>> (sometime trying to mount rootfs, sometimes a little further trying to bring >>> networking up.) >> ... but apparently does (apart from also having the intended effect >> of eliminating vector-without-IRQ warnings). But it's not obvious >> how that would be - after all, the two added calls should be pretty >> benign performance wise. >>> I don't see any evident warnings or errors, reverting this commit makes the >>> system boot OK again. >> Does the watchdog work on it? If so, could you see whether enabling >> that catches something? Or else, do the debug keys still work when >> the box stopped? > Yes they still work, and somehow using the debug keys seems to make it continu for a bit (slowly and ending up in infinite loop printing firewall messages) > > Serial log attached, hope i have used the debug keys you are interested in, if not please do specify ... > > -- > Sander hpet_msi_mask() flips the Timer Interrupt Enable bit, which causes the timer not to generate interrupts, but to continue running. Are we by any chance suffering from a bad interaction of oneshot timers not being re-armed for exceedingly long periods of time ? ~Andrew > > >> Jan