Re: [Xen-devel] Re: [Patch RFC] ttm: nouveau accelerated on Xen pv-ops kernel

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

> > So just to be sure, you took the 2.6.32 (xen/next or
> > xen/stable-2.6.32.x), copied the include and nouveu directory from ..?
> > 2.6.33? and then ran this.
> 
> I actually took a slightly more sadistic route than Arvind... ;-)  A while 
> back, I backported the important stuff from the Nouveau kernel git tree 
> back to v2.6.31.  Basically guessed at which commits were important, wrote 
> a script to cherry pick each and every one, and spent an entire day 
> reading commit logs, resolving conflicts, and figuring out which other 
> non-drm commits I needed.  Sounds retarded, I know, but it was a pretty 
> interesting way to get myself up to speed with the code base.  The 
> resulting 2.6.31-nouveau kernel runs like a champ on all my hardware.

That is ambitious.
> 
> Then I merged that into my clone of Jeremy's xen/master which I use with 
> Xen 3.4.2.
> 
> Since then, I've been periodically cherry picking all new commits off the 
> nouveau tree.  Also had to rebuild Xorg 7.5 to use xorg-server 1.7.5, new 
> libdrm, mesa, and xf86-video-nouveau all from their respective git trees 
> as of yesterday.  (drm and xf86-video-nouveau are on their master 
> branches, mesa is on the 7.8 branch)
> 
> This all works great using xen/master bare metal.  It used to work fine on 
> my old GeForce2 MX based systems in Xen.  Arvind's patch made it work on 
> my nice new systems in Xen, but broke it on the old ones.  Everything 
> still works fine bare metal.
> 
> > Did you have to edit your xorg.conf file or
> > it ran just fine? 
> 
> Well, I had to create an xorg.conf that looks like this:
> 
> Section "Device"
>   Identifier "foo"
>   Driver "nouveau"
> EndSection
> 
> Otherwise it uses the 'nv' driver...  and I haven't stumbled onto how to 
> get nouveau to automatically get used (aside from uninstalling the nv 
> driver).
> 
> 
> > Was this Fedora 13 or Fedora 12?
> 
> This is all being done on a custom 32bit Linux distro that we use for our 
> tightly configuration controlled system deliveries.  It was fedora based a 
> looooooooong time ago (FC5), but is completely unrecognizable now.

Ah, so it is 32-bit, not 64-bit.
> 
> 
> > Arvind explanation about the Nvidia driver pointed out that the NVidia
> > driver (drm/nouvue) can operate on different channels. Where channel 1
> > is the framebuffer, and the other are for well, KMS, and other
> > applications.
> > 
> > I belive I was looking at the wrong section of the drivers (not the
> > drivers/video/gpu ones)- this certainly looks to be the issues the 
> > Jeremy mentioned.
> > 
> > Also I would suggest you load drm with the debug variable set to the 255
> > to get most of what his happening. 
> 
> I'll try that.
> 
> 
> > Based on your strace, the last call is:
> > 4000)                          = 0x9324000
> > write(0, "(II) NOUVEAU(0): Opened GPU chan"..., 38) = 38 
> > ioctl(11, 0xc0106445, 0x930a908)        = 0 
> > ioctl(11, 0x400c6444, 0xbfd2a210)       = 0 
> > +++ killed by SIGKILL +++
> > 
> > I cannot find what 0x45 is in the upstream Linux, so you must be using a
> > different nouv* driver than that. The 0x44 is:
> > 
> >   DRM_IOCTL_DEF(DRM_NOUVEAU_GEM_INFO, nouveau_gem_ioctl_info, DRM_AUTH),
> > 
> > Which looks to be pretty harmless. I presume it is the next thing (using
> > the address returned) that the X driver tries to do that makes it go 
> boom.
> 
> I've never used strace before... how do you map between the ioctl 
> definitions and the hex addresses?

The IOCTL numbers are generated by this macro:

#define DRM_IOCTL_BASE                  'd'
#define DRM_IO(nr)                      _IO(DRM_IOCTL_BASE,nr)

#define _IOC(dir,type,nr,size) \
        (((dir)  << _IOC_DIRSHIFT) | \
         ((type) << _IOC_TYPESHIFT) | \
         ((nr)   << _IOC_NRSHIFT) | \
         ((size) << _IOC_SIZESHIFT))

#define _IO(type,nr)            _IOC(_IOC_NONE,(type),(nr),0)

and the values are:
_IOC_NRSHIFT = 0
_IOC_TYPESHIFT = 8
_IOC_SIZESHIFT = 16
_IOC_DIRSHIFT = 30

Which basically translates that the 0 through 8 bits are the 'nr' (0x44),
8 throught 16 are the 'type' (which is the letter 'd'), and the 16
through 30 is the size of the structure, and the last two bits are for
direction, which in this case is the value '0'.

At least that is what I think it translates too. Now I am not certain
anymore..
> 
> 
> ---
> Michael D Labriola
> Electric Boat
> mlabriol@xxxxxxxx
> 401-848-8871 (desk)
> 401-848-8513 (lab)
> 401-316-9844 (cell)
> 

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