From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: New release candidate for Xen 4.0.0 (RC9) Date: Wed, 26 May 2010 11:02:11 -0400 Message-ID: <20100526150211.GB24174@phenom.dumpdata.com> References: <20100331210716.GA31475@phenom.dumpdata.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline 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: Keir Fraser Cc: "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org On Wed, May 19, 2010 at 01:10:36PM +0100, Keir Fraser wrote: > On 31/03/2010 22:07, "Konrad Rzeszutek Wilk" wrote: > > >> I'm only interested in fixing regressions right now for 4.0.0. If this bug > >> has existed since at least 3.4 then the fix (when we have one!) can wait a > >> bit longer, for 4.0.1. My guess is that the MTRR interface is getting little > > > > Yeah. I get the same failure with 3.4 from xen-3.4-testing: > > I didn't reproduce this with my setup, but the crash below is because > spin_unlock() is finding that the lock is not locked on entry. This is the > set_atomicity_lock as acquired/released by prepare_set/post_set. Looking at > the code they seem to be used in matched pairs and I can't see any memory > corruption issues or anything. If you want to get this fixed then you'll > have to add some tracing to find out what's going on (e.g, dump the lock > state at the end of prepare_set and start of post_set). If you can reproduce > this deterministically with your setup then should be pretty easy to nail > this bug. OK. Thanks.