This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

To: Michael D Labriola <mlabriol@xxxxxxxx>
Subject: Re: [Xen-devel] Re: [Patch RFC] ttm: nouveau accelerated on Xen pv-ops kernel
From: Arvind R <arvino55@xxxxxxxxx>
Date: Thu, 18 Mar 2010 11:39:08 +0530
Cc: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx, Jeremy Fitzhardinge <jeremy@xxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, Joanna Rutkowska <joanna@xxxxxxxxxxxxxxxxxxxxxx>, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Delivery-date: Wed, 17 Mar 2010 23:09:53 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=MqsXkhABfXmbZ7E8JiSrJvmnNPfGLe3KQEz6PdGYiBU=; b=niB4F1jJ9d9GgHN727UuRr0PEcdGcHj1ysQxwUmNHlSi/8tmBfUZ7cAITMiZ0G5Hfz ufoacSSBUHtWqTlVzQDIpxCD47OQOC6tZKXYC7E+LKOPX8uMEb1Wk4Y8u5bMP/k02kLu ywxvhp0w/lia8cQ/d8W3piCuwIK87+v7TO0KM=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=OAkv/UFwZMlPXnhtJu9rAC0Fb76yXnQOP1kSlMI/tqxFR5uh8e9i2dwPMCpHztmOJl bmQijZdWwjMKgWMptZdM6OgC1qDfAiNF6qTCPiOj9u/T5Q+eLbifrm/qRY4YeF7oJNnq GO5O0+eVqBPj1yawUJhloRnKDMv+47UyjQ3F4=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <OFD9E335AB.B4CBDD9D-ON852576E8.00682C84-852576E8.006BF5A6@xxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <20100316172135.GA25753@xxxxxxxxxxxxxxxxxxx> <OFD9E335AB.B4CBDD9D-ON852576E8.00682C84-852576E8.006BF5A6@xxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Wed, Mar 17, 2010 at 1:09 AM, Michael D Labriola <mlabriol@xxxxxxxx> wrote:
> Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> 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.  If 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'.  Figuring
> out
>> > which mapping the fault is happening in is a little over my head, I'm
>> > afraid.  If 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... ;-)  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.
> 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.
>> 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 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 switch 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 initialisation
- which maybe the problem. Do you have modeset=1 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 suspect.

> I've never used strace before... how do you map between the ioctl
> definitions and the hex addresses?
> ---
> Michael D Labriola
> Electric Boat
> mlabriol@xxxxxxxx
> 401-848-8871 (desk)
> 401-848-8513 (lab)
> 401-316-9844 (cell)

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>