WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [GIT PULL] for-2.6.32/bug-fixes

To: Jan Beulich <JBeulich@xxxxxxxxxx>
Subject: Re: [Xen-devel] [GIT PULL] for-2.6.32/bug-fixes
From: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Date: Wed, 18 May 2011 10:56:44 -0400
Cc: jeremy@xxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 18 May 2011 07:58:23 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4DD3F4670200007800041E55@xxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4DD373C0020000780007014D@xxxxxxxxxxxxxxxxxx> <20110518132442.GB3238@xxxxxxxxxxxx> <4DD3F4670200007800041E55@xxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.21 (2010-09-15)
On Wed, May 18, 2011 at 03:31:35PM +0100, Jan Beulich wrote:
> >>> On 18.05.11 at 15:24, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> 
> >>> wrote:
> >> >Well, req->ns_segments = 0, so nseg is zero, which means all
> >> >of those for loops never get executed.
> >> 
> >> This you say is the case for the request you saw the failure with, or
> >> *all* barrier requests? In the latter case, what do you conclude this
> > 
> > Good question. It was the first barrier request sent when guest tried to
> > mount the filesystem. I will instrument the code to see what the other
> > barriers contained when they were sent.
> 
> That wouldn't tell you anything if they're all empty, as there's nothing
> preventing other guests (including other guest OSes) to still send
> non-empty ones - after all the protocol allows for this.

Aha! That is what you been trying to tell me. I will make a patch to make
sure to not overwrite the req->sector_number blindly. What other guest OSes
use barriers? I looked at Solaris (it uses 'feature-flush-cache'), NetBSD
('feature-flush-cache') and Linux ('feature-barrier' and now in 2.6.40
'feature-flush-cache').

The GPLV Windows drivers have no barrier implementation - do you know if
the Novell ones are using barriers?

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel