[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On Thu, Oct 15, 2009 at 04:04:09PM -0400, Konrad Rzeszutek Wilk wrote:
> > > 
> > > 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.
>

It seems there are two separate issues; the radeon/drm failure, and then the 
USB problem.
More about USB later in this mail.

I hacked the initrd and added 'debug=255' when modprobing drm.ko.
Log below.

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

True, I missed that. But the modesetting actually works on that fedora kernel, 
so it's
probably driver version related, since fedora has newer gfx stuff than
upstream kernel (some of the drm/radeon developers are fedora developers so the 
patches 
end up in fedora kernels before upstream kernels).

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

Done.

> > plymouth --show-splash
> > 
> > So I guess plymouth is asking for a graphics mode..
> 
> Add this to your kernel command line: plymouth:debug

Done.

Log with the modifications:
http://pasik.reaktio.net/xen/pv_ops-dom0-debug/radeondebug/dmesg-2.6.31.1-2009-10-16-drmdebug.txt

Still same problems related to radeon:
[drm:radeon_ring_test] *ERROR* radeon: ring test failed 
(sracth(0x15E4)=0xCAFEDEAD)
[drm:r100_cp_init] *ERROR* radeon: cp isn't working (-22).


Then more about USB stuff:

usb 1-5: new high speed USB device using ehci_hcd and address 2
<huge list of backtraces>

I think those USB devices are the IPMI management devices for remote KVM
(keyboard/video/mouse).. shouldn't make any difference I guess..


-- Pasi


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.