From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arvind R Subject: Re: Re: [Patch RFC] ttm: nouveau accelerated on Xen pv-ops kernel Date: Thu, 18 Mar 2010 11:39:08 +0530 Message-ID: References: <20100316172135.GA25753@phenom.dumpdata.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Michael D Labriola Cc: xen-devel-bounces@lists.xensource.com, Jeremy Fitzhardinge , xen-devel@lists.xensource.com, Joanna Rutkowska , Konrad Rzeszutek Wilk List-Id: xen-devel@lists.xenproject.org On Wed, Mar 17, 2010 at 1:09 AM, Michael D Labriola wro= te: > Konrad Rzeszutek Wilk wrote on 03/16/2010 > 01:21:35 PM: > >> > > > And my X log ends abruptly after this line: >> > > > (II) NOUVEAU(0): Opened GPU Channel 1 >> > > > >> > > > Any ideas? >> > > > >> > > >> > > Well, this is generally the symptom that someone is confusing mfns > and >> > > pfns, and therefore ends up incorrectly setting the _PAGE_IO flag in > >> > > some pte. =A0If you run it under strace, can you identify which > mapping >> > > the fault is happening in? >> > >> > I've attached the output of 'strace -o strace-Xorg Xorg'. =A0Figuring > out >> > which mapping the fault is happening in is a little over my head, I'm >> > afraid. =A0If you need different arguments to strace, let me know and > I'll >> > do it again. >> >> 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... ;-) =A0A wh= ile > back, I backported the important stuff from the Nouveau kernel git tree > back to v2.6.31. =A0Basically guessed at which commits were important, wr= ote > 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. =A0Sounds retarded, I know, but it was a pretty > interesting way to get myself up to speed with the code base. =A0The > resulting 2.6.31-nouveau kernel runs like a champ on all my hardware. > > 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. =A0Also had to rebuild Xorg 7.5 to use xorg-server 1.7.5, n= ew > libdrm, mesa, and xf86-video-nouveau all from their respective git trees > as of yesterday. =A0(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. =A0It used to work fine= on > my old GeForce2 MX based systems in Xen. =A0Arvind's patch made it work o= n > my nice new systems in Xen, but broke it on the old ones. =A0Everything > 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" > =A0Identifier "foo" > =A0Driver "nouveau" > EndSection > > Otherwise it uses the 'nv' driver... =A0and I haven't stumbled onto how t= o > 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. =A0It was fedora base= d a > looooooooong time ago (FC5), but is completely unrecognizable now. > > >> 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) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D 0x9324000 >> write(0, "(II) NOUVEAU(0): Opened GPU chan"..., 38) =3D 38 >> ioctl(11, 0xc0106445, 0x930a908) =A0 =A0 =A0 =A0=3D 0 >> ioctl(11, 0x400c6444, 0xbfd2a210) =A0 =A0 =A0 =3D 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: >> >> =A0 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 suspect that the ioctl is prior to a modeset operation. And the mode-setting is 'booming'. My kernel config has VGA console built-in fbcon as a module and I do a swit= ch to nouveaufb at runlevel 2. Also note that the default modeset parameter is -1= and if VGA-CONSOLE is enabled, then modeset is set to 0 in the driver initialis= ation - which maybe the problem. Do you have modeset=3D1 as module parameter? As to the implications of Thomas' remark on the possibility of placement migration 'tween mmap and fault; and the over-loading of VM_IO semantics; (points 1 and 2), - that seems to be a problem to be resolved. VM_MIXEDMAP would not be a problem if VM_IO semantics were consistent with Xen, I suspe= ct. > I've never used strace before... how do you map between the ioctl > definitions and the hex addresses? > > > --- > Michael D Labriola > Electric Boat > mlabriol@gdeb.com > 401-848-8871 (desk) > 401-848-8513 (lab) > 401-316-9844 (cell) > > >