From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: [linux-linus test] 25478: regressions - FAIL [and 1 more messages] Date: Wed, 16 Apr 2014 10:11:52 -0400 Message-ID: <20140416141151.GA8403@phenom.dumpdata.com> References: <201404161149.s3GBnQn8001554@aserz7022.oracle.com> <21326.29230.302456.997315@mariner.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <21326.29230.302456.997315@mariner.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Jackson Cc: Boris Ostrovsky , Xen Devel , Ian Campbell , David Vrabel List-Id: xen-devel@lists.xenproject.org On Wed, Apr 16, 2014 at 01:06:06PM +0100, Ian Jackson wrote: > Konrad Rzeszutek Wilk writes ("Re: [Xen-devel] [linux-linus test] 25478: regressions - FAIL [and 1 more messages]"): > > On Apr 16, 2014 6:12 AM, Ian Jackson wrote: > > > Another week has gone by and Linux tip still fails this test. > > > > Did you try the recommendation that David offered - boot with 4GB to dom0? > > That would be a workaround. I can do that (as it happens these > machines have 8G of RAM so it is actually possible), but: Right. > > The purpose of running tests is to discover bugs (so that they can be > fixed). It is not to generate a nice clean report by sweeping things > under the carpet. Right. > > Here the tests have discovered a bug in Linux. AIUI it's a bug which > is visible when using this particular driver, but which is actually a > problem with the Xen integration into the Linux VM system in general. > So other it presumably affects other drivers too. It should be fixed, > not worked around. I concur. > > The downside of not working around this bug is that osstest's > failing-host-stickiness will cause an increasing proportion of the > tests to run on the affected hosts. This might mask other bugs. > > Conversely, working around this bug in the manner suggested will > presumably just make the bug disappear off our radar. There is a danger of that. I am not going to be able to take a look at this bug in the next three weeks. If anybody else wants to take a stab at this - here is my hand-waving idea of how it could be done: 1). Cleanup the ia64 usage of same code 'ia64_dma_get_required_mask' (it actually duplicates what the drivers/base has). Perhaps move it to lib/iommu-helper.c Call it 'generic_get_required_mask' or such. 2). Look at other platforms that use a similar (or the same) code and see if they can re-use it now that it is in lib/iommu-helper.c. 3). Make the x86 dma_ops start using the extra "get_required_mask" and point it to the generic_get_required_mask. 4). Make the xen-swiotlb use its own version. > > Ian.