From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bruce Edge Subject: Re: Re: 2.6.37-rc1 mainline domU - BUG: unable to handle kernel paging request Date: Sun, 14 Nov 2010 13:35:54 -0800 Message-ID: References: <20101112170143.GC10339@dumpdata.com> <503106.98736.qm@web56107.mail.re3.yahoo.com> <1835258992.20101114175648@eikelenboom.it> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <1835258992.20101114175648@eikelenboom.it> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Sander Eikelenboom Cc: Boris Derzhavets , xen-devel@lists.xensource.com, Jeremy Fitzhardinge , Konrad Rzeszutek Wilk List-Id: xen-devel@lists.xenproject.org On Sun, Nov 14, 2010 at 8:56 AM, Sander Eikelenboom wrote: > Hmmm have you tried do do a lot of I/O with something else as NFS ? > That would perhaps pinpoint it to NFS doing something not completely comp= atible with Xen. I have my own suspicions regarding the more recent NFS clients. Post 10.04 Ubuntu variants do not tolerate large NFS transfers even without Xen. Any more than a few 100 Megs and you start getting 'task blocked for more than 120 sec..." messages along with stack traces showing part of the NFS call stack. Perhaps a parallel effort could be to test the 2.6.37-rc1 kernel with something other than NFS for remote filesystems. I'll see if I get the same problems with glusterfs. -Bruce > > I'm not using NFS (I still use file: based guests, and i use glusterfs (f= use based userspace cluster fs) to share diskspace to domU's via ethernet). > I tried NFS in the past, but had some troubles setting it up, and even mo= re problems with disconnects. > > I haven't seen any "unable to handle page request" problems with my mix o= f guest kernels, which includes some 2.6.37-rc1 kernels. > > -- > > Sander > > > > > > Sunday, November 14, 2010, 5:37:59 PM, you wrote: > >> I've tested F14 DomU (kernel vmlinuz-2.6.37-0.1.rc1.git8.xendom0.fc14.x8= 6_64) as NFS client and Xen 4.0.1 F14 Dom0 (kernel vmlinuz-2.6.32.25-172.xe= ndom0.fc14.x86_64) as NFS server . Copied 700 MB ISO images from NFS folder= at Dom0 to DomU and scp'ed them back to Dom0. During about 30 - 40 min Dom= U ran pretty stable , regardless kernel crash as "unable to handle page req= uest" was reported once by F14 DomU, but it didn't actually crash DomU. Sam= e excersises with replacement F14 by Ubuntu 10.04 Server results DomU crash= in about several minutes. Dom0's instances dual boot on same development b= ox ( Q9500,ASUS P5Q3,8GB) > >> Boris. > >> --- On Fri, 11/12/10, Konrad Rzeszutek Wilk wro= te: > >> From: Konrad Rzeszutek Wilk >> Subject: Re: [Xen-devel] Re: 2.6.37-rc1 mainline domU - BUG: unable to h= andle kernel paging request >> To: "Sander Eikelenboom" >> Cc: "Boris Derzhavets" , xen-devel@lists.xensourc= e.com, "Bruce Edge" , "Jeremy Fitzhardinge" >> Date: Friday, November 12, 2010, 12:01 PM > >> On Fri, Nov 12, 2010 at 05:27:43PM +0100, Sander Eikelenboom wrote: >>> Hi Bruce, >>> >>> Perhaps handpick some kernels before and after the pulls of the xen pat= ches (pv-on-hvm etc) to begin with ? >>> When you let git choose, especially with rc-1 kernels, you will end up = with kernels in between patch series, resulting in panics. > >> Well, just the bare-bone boot of PV guests with nothing fancy ought to w= ork. > >> But that is the theory and .. >>> > The git bisecting is slow going. I've never tried that before and I'm= a git >>> > rookie. >>> > I picked 2.6.36 - 2.6.37-rc1 as the bisect range and my first 2 bisec= ts all >>> > panic at boot so I'm obviously doing something wrong. >>> > I'll RTFM a bit more and keep at it. > >> .. as Bruce experiences this is not the case. Hmm.. > >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xensource.com >> http://lists.xensource.com/xen-devel > > > >> > > > > -- > Best regards, > =A0Sander =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0mailto:l= inux@eikelenboom.it > >