From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: General protection fault in netback Date: Tue, 21 Feb 2012 11:58:30 -0500 Message-ID: <20120221165830.GA32413@phenom.dumpdata.com> References: <20120209211316.GD14007@andromeda.dapyr.net> <20120215183122.GO12984@reaktio.net> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Anton Samsonov Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org On Tue, Feb 21, 2012 at 06:06:14PM +0300, Anton Samsonov wrote: > 2012/2/15 Pasi K=E4rkk=E4inen : > = > AS>> Unfortunately, I'm not skilled at compiling the kernel myself. > AS>> I tried building the newest 3.2.6 with all Xen options enabled, > AS>> but the resulting system didn't have netback.ko module at all, > AS>> barely booted, and xm was not able to communicate with VMM. > = > PK> About compiling the dom0 kernel, see this wiki page: > PK> http://wiki.xen.org/wiki/XenParavirtOps#Configure_kernel_for_dom0_sup= port > = > Thanks, it looks like I just messed some "y" with "m" and vice versa > ("m" is presented as a meaningless bullet in GUI). By the way, that how-to > contains dubious lines for CONFIG_XEN_DEV_EVTCHN and CONFIG_XEN_GNTDEV. > = > Well, now the system boots more eagerly, although the kernel still > seems to be slightly incompatible with distro's environment and my hardwa= re. > But at least xend is now responding and is able to run DomUs as usual. > = > = > I started and stopped all the swarm of VMs several times (without letting= them > to run for some time), and observed no GPF. But instead of this I get > screen garbling: while a DomU is starting or stopping, the whole graphical > desktop is sometimes painted with either black or not-so-random garbage, > and even mouse pointer can become garbled; I have to move / resize windows > to get them repainted. Network connectivity between Dom0 and [subsequently > started] DomUs does not break though. > = > On one hand, I am not sure whether the video driver is not to be > blamed for glitches, > because graphics already does not work as usual: it is not hardware-accel= erated > with my custom kernel (while it is with stock kernel), and the screen is = garbled > on Xorg startup, before login promt is displayed. On the other hand, this= is not So... I am curious, what graphic card do you have and do you get any of these Red Hat BZs? RH BZ# 742032, 787403, and 745574? > in any way normal, as Xen operations must not interfere with Dom0's deskt= op > (or was it direct VRAM corruption?). It is complicated. There is a bug in 3.2 when using radeon or nouveau for a= lengthy time of period that ends up "corrupting" memory. The workaround is to provi= de 'nopat' on the argument line. > = > This happens even when "suspicious" domains (NetBSD with CARP) are not > started: on a freshly booted Dom0, just having 4 essential DomUs is enough > to get that screen garbling when shutting down 1 or 2 of them for the > first time. Hmm, that is weird. Never seen that before. Can you include more details on= your machine? > = > = > But when I return to stock kernel, I can run a dozen of such DomUs (inclu= ding > those NetBSD load-balancers), starting and stopping them many times > without a problem. Recently, no GPF occurred when only 1 out of 2 balance= rs > is started, or none of them started at all; or it just needs much more up= time > to accumulate memory corruption for a GPF. > = > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel