From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: Announcing xen/master: pvops git trees rearranged Date: Mon, 12 Oct 2009 16:02:48 -0400 Message-ID: <20091012200248.GA16486@phenom.dumpdata.com> References: <4AB431AD.1030205@goop.org> <20091011153900.GW1434@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: <20091011153900.GW1434@reaktio.net> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= Cc: Jeremy Fitzhardinge , Xen-devel List-Id: xen-devel@lists.xenproject.org On Sun, Oct 11, 2009 at 06:39:00PM +0300, Pasi K=E4rkk=E4inen wrote: > On Fri, Sep 18, 2009 at 06:19:41PM -0700, Jeremy Fitzhardinge wrote: > >=20 > > This is definitely a work-in-progress kernel. I'd appreciate all bug > > *and* success reports so I can get some idea of how many people are > > using this thing, and how often there are problems. Patches grateful= ly > > accepted. > >=20 >=20 > I just tried the latest pv_ops dom0 git tree (11 Oct 2009) on x86_64 AH= CI box. >=20 > The good news is that the dom0 kernel boots up, but there are some erro= r > messages. >=20 > Using the default options (modeset) the VGA console doesn't work, it > goes blank (display says "power save") in the beginning of dom0 kernel = boot: > http://pasik.reaktio.net/xen/pv_ops-dom0-debug/dmesg-2.6.31.1-2009-10-1= 1.txt This line: [drm:radeon_ring_test] *ERROR* radeon: ring test failed (sracth(0x15E4)=3D= 0xCAFEDEAD) Is a pretty good pointer at what the fault is. If you look at git commit 93e7c3850b8431e19c9cba91413066bfd2360671 you will see the band-aid Jeremy= added. It looks though as if not all of the radeon drivers allocate their ring b= uffer memory via drm_sg_alloc calls thought. Not sure how the r100 (and the corresponding = X driver) does it. The long/erro traceback about the HARDIRQ is a red-herring in this case. Here is a couple of things that I would like you to try, if you can: 1). Pass in 'drm.debug=3D255' and send the output. It should have tons of= extra output.=20 2). Send in the Xorg.log (or whatever output the program in the userland = that starts the modesetting produces). I don't have much knowledge in how mo= desetting works, so this might require some digging. 2). When you boot the kernel without Xen, you don't see this error, right= ? 3) What does lspci -vvv output show for the video card in question?