Re: Announcing xen/master: pvops git trees rearranged

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

On Thu, Oct 15, 2009 at 12:14:15AM +0300, Pasi Kärkkäinen wrote:
> 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

I forgot to mention that you probably need to have CONFIG_DRM set to 'y' instead of 'm'
for this to work. Or you could hack up the initrd (modprobe.conf) and make drm load
with the 'debug=255' parameter.

.. snip ..

> 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

Nah. Still has the same problem:

[drm:r100_ring_test] *ERROR* radeon: ring test failed (sracth(0x15E4)=0xCAFEDEAD)
[drm:r100_cp_init] *ERROR* radeon: cp isn't working (-

> 
> 
> > 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

add here:
export LIBGL_DEBUG=verbose

> plymouth --show-splash
> 
> So I guess plymouth is asking for a graphics mode..

Add this to your kernel command line: plymouth:debug