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/
Home Products Support Community News


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.


Xen-devel mailing list