From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: blkfront problem in pvops kernel when barriers enabled Date: Tue, 6 Sep 2011 12:32:13 -0400 Message-ID: <20110906163213.GC5264@dumpdata.com> References: <4E6357C6.6050101@mimuw.edu.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <4E6357C6.6050101@mimuw.edu.pl> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Marek Marczykowski Cc: "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org On Sun, Sep 04, 2011 at 12:49:42PM +0200, Marek Marczykowski wrote: > Hello, > > Pvops block frontend (tested vanilla 3.0.3, 3.1rc2, Konrad's testing > branch) produces a lot of I/O errors when barriers are enabled but > cannot be used. > > On xenlinux I've got message: > [ 15.036921] blkfront: xvdb: empty write barrier op failed > [ 15.036936] blkfront: xvdb: barriers disabled > > and after that, everything works fine. On pvops - I/O errors. > As backend I've used 2.6.38.3 xenlinux (based on SUSE package) and > 3.1rc2 with same result. Hm, and the 'feature-barrier' was enabled on in those backends? That is really bizzare considering that those backends don't actually support WRITE_BARRIER anymore. > > When I disable barriers (patching blkbackend to set feature-barrier=0) > everything works fine with all above versions. Ok, and the patch you sent "[PATCH] Initialize vars in blkfront_connect" as well? > > My setup is xen-4.1.1 (if it matters), backends: phy from device-mapper > device and phy from loop device; frontends covered by device-mapper > snapshot, which is set up in domU initramfs. > > It looks like some race condition, because when I setup device-mapper in > domU and mount it manually (which cause some delays between steps), it > works fine... > > Have you idea why it happens? What additional data can I provide debug it? > > In addition it should be possible to disable barrier without patching > module... Perhaps some pciback module parameter? Or leave feature-* Not sure why you would touch pciback.. But the barrier should _not_ be enabled in those backends. The 'feature-flush-cache' should be. > xenstore entries alone if present before device initialization. > > -- > Pozdrawiam / Best Regards, > Marek Marczykowski | RLU #390519 > marmarek at mimuw edu pl | xmpp:marmarek at staszic waw pl > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel