[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



>>> On 18.05.11 at 16:56, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> wrote:
> 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

Or use the patch I proposed?

> 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?

No, I don't.

Jan


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.