Re: Nouveau on dom0

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

On Thu, Feb 25, 2010 at 02:16:07PM +0530, Arvind R wrote:
> Hi all,
> I merged the drm-tree from 2.6.33-rc8 into jeremy's 2.6.31.6 master and
> got X working on dom0 - but only with option "ShadowFB" set. Using Xorg-7.5,
> mesa-git, libdrm-git xf86-video-nouveau-git, xen-testing-git and
> qemu-dm-git. Ensured dependencies by deb-packaging everything. Kernel
> built without drm and the nouveau driver built as a separate
> out-of-tree modules package- to ensure
> correct ttm modules. Tried WinXP and debianetch domUs - which worked fine.
> 
> On bare-metal boot, everything works - even 3D accelerated rendering. But
> when booted on Xen, X works ONLY - as mentioned - with ShadowFB set,
> which in turn, turns off even 2D acceleration. The only difference in the boots
> is that bare-metal boot has 2GB RAM whereas dom0 has 512M. The graphics
> card is a nVidia GeForce 9400GT, and the distro is basically debian lenny.
> 
> Turned debug on in the nouveau driver and patched some into libdrm and
> compared the outputs on bare-metal and xen boot. Identical output upto
> problem point - only differing fields were time-stamp, process pid, and
> grobj allocation addresses.
> 
> Problem Point:
> libdrm has an inlined function OUT_RING, defined in
> nouveau/nouveau_pushbuf.h.
> static __inline__ void
> OUT_RING(struct nouveau_channel *chan, unsigned data)
> {
>     *(chan->cur++) = (data);
> }
> - chan->cur is a uint32_t *
> 
> The function is entered by X through ScrnInit in the DDX driver.
> Patched log-message on entry is written to syslog, and then -
> X seems to get suspended. chan->cur can be read on entry,
> so (assumed) suspension is on write. System loses consoles,
> but can be ssh'ed into - no killed processes, no segfault.
> 
> The area pointed to be the pushbuf - which is apparently the
> PRAMIN area on the graphics card. Modern graphics is not
> my forte - so I am seeking some pointers to resolve this from

So this looks to assume that the ring is contingous, which it probably
is not. Would it be possible to trace down who allocates that *chan? You
say it is 'PRAMIN' - is that allocated via pci_alloc_* call?

Or is the address retrieved from an ioctl call made in user-space?

> anyone. I think that if this is solved, Xen would have open-source
> 3D-acceleration support! Am game for testing, patching, etc.

Neat!
> 
> I am basically interested in having a develepment domU and
> another testing domU without devel-packages.

You lost me here. Don't you mean Dom0?