Re: [Xen-devel] Announcing xen/master: pvops git trees rearranged

[Pasi Kärkkäinen <pasik@xxxxxx>]

On Mon, Oct 12, 2009 at 04:02:48PM -0400, Konrad Rzeszutek Wilk wrote:
> On Sun, Oct 11, 2009 at 06:39:00PM +0300, Pasi Kärkkäinen wrote:
> > On Fri, Sep 18, 2009 at 06:19:41PM -0700, Jeremy Fitzhardinge wrote:
> > > 
> > > 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 gratefully
> > > accepted.
> > > 
> > 
> > I just tried the latest pv_ops dom0 git tree (11 Oct 2009) on x86_64 AHCI 
> > box.
> > 
> > The good news is that the dom0 kernel boots up, but there are some error
> > messages.
> > 
> > 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-11.txt
> 
> This line:
> [drm:radeon_ring_test] *ERROR* radeon: ring test failed 
> (sracth(0x15E4)=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 
> buffer 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:
> 

Sure.

> 1). Pass in 'drm.debug=255' and send the output. It should have tons of extra
> output. 
> 

http://pasik.reaktio.net/xen/pv_ops-dom0-debug/radeondebug/dmesg-2.6.31.1-2009-10-14-drmdebug.txt

Unknown boot option `drm.debug=255': ignoring

Also it seems this error:
[ INFO: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected ]

.. comes from the USB stuff.

I tried Fedora xendom0 kernel rpm, and the kernel graphics modesetting
seems to work there! (Fedora kernel contains newer graphics/drm drivers).

But the same USB related error is there with the fedora kernel:
[ INFO: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected ]

http://pasik.reaktio.net/xen/pv_ops-dom0-debug/radeondebug/dmesg-2.6.31.3-1.2.71.xendom0.fc12.x86_64-2009-10-14.txt


> 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 
> modesetting works,
>  so this might require some digging.
> 

Hmm.. yeah, I'm not sure either which is the first program setting up
graphics mode using kernel modesetting (KMS) in Fedora.. 

I extracted the initrd image and checked the 'init' script:

echo "Loading drm module"
modprobe -q drm
echo "Loading ttm module"
modprobe -q ttm
echo "Loading radeon module"
modprobe -q radeon
/lib/udev/console_init tty0
plymouth --show-splash

So I guess plymouth is asking for a graphics mode..


> 2). When you boot the kernel without Xen, you don't see this error, right?
> 

Yeah, it works OK on baremetal without Xen.
http://pasik.reaktio.net/xen/pv_ops-dom0-debug/radeondebug/dmesg-2.6.31.1-baremetal.txt

> 3) What does lspci -vvv output show for the video card in question?
> 

http://pasik.reaktio.net/xen/pv_ops-dom0-debug/radeondebug/lspci-vvv-2.6.31.1-baremetal.txt
http://pasik.reaktio.net/xen/pv_ops-dom0-debug/radeondebug/lspci-vvv-2.6.31.1-dom0.txt

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel