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, 25 Mar 2010 12:35:06 +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: Thu, 25 Mar 2010 00:05:44 -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=t/rMSyPw7ScaimXTyHWaOHBzSIlqUdzJc1UvN6BmuZw=; b=NweLTPRppdEyEdV6y5eAwJX86iNQUP1p66gAMfuJqdJ+ga4QqnVxU+OzboCaAOljUX J6IdvrvIXvACEW783BjX8oivY/SjLb0j/XaTcKxQocA2fUQgHtw5WCDCd16bjEt63D5K aMQ/QccV+GuJw2FIU1yTqOHp5LjCU5rb8ptZk=
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=FGrgcxjCKVtuUqwkGbQtB5byiJ1pWezOJeLBXXMX58LGs0n5ukTsGAYEAQC5W8mTi8 466WlwIdniwdakXRbfzMwXKRb0bAorxgjgcQMDjoLZMWzDt+hCn/1WfQcePx0kauQxy9 UDslvNou5CtUcgpIgFvGmbtZ586WY26OO5b7A=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <OF93927082.873B0041-ON852576EF.0048A2E2-852576EF.0049E6F8@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: <d799c4761003222321o26d816acsec2ac64be9797eda@xxxxxxxxxxxxxx> <OF93927082.873B0041-ON852576EF.0048A2E2-852576EF.0049E6F8@xxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Tue, Mar 23, 2010 at 6:57 PM, Michael D Labriola <mlabriol@xxxxxxxx> wrote:
> xen-devel-bounces@xxxxxxxxxxxxxxxxxxx wrote on 03/23/2010 02:21:31 AM:
> *snip*
>> > with "NOUVEAU(0): Opened GPU channel 1".
>> This is strange - channel 1 is the console channel. This appears in
> dmesg on
>> nouveaufb initialisation before EDID probe to find connected outputs.
>> Start X manually to avoid confusion of logs.
>> Have attached ttm_xen.patch which updates vm_page_prot after changing
> flags.
>> This is not done in the mainline drm-tree. But in the xen (old)
>> drm-tree this is done in
>> BOTH ttm_bo_mmap AND ttm_fbdev_mmap - and the attached patch does both,
>> along with the conditional VM_IO in bo_mmap. And the second vm_page_prot
>> update is for fbdev_mmap which corresponds to channel 1. Cross
>> fingers and try!
> Actually, both hunks of that patch are already applied in my tree.  The
> git tree from git://anongit.freedesktop.org/nouveau/linux-2.6 appears to
> already be doing the vm_page_prot update in both places.  Maybe the
> official nouveau dev tree is hosed?  Odd that it would work fine
> bare-metal...

It always did work on bare-metal and on Xen without acceleration.
The patch just enables acceleration on Xen - it seems only on PCI/E cards.

> *snip*
>> >> Xorg used to hang saying 'Opened Channel 2' and not 1.
>> >
>> > Now that's strange.  Every single one of my boxes says Opened Channel
> 1,
>> > with now reference to channel 2 at all.
>> Try with
>> Option "ShadowFB"  "true"
>> in Device section of xorg.conf (turns off acceleration) to check. The
> option
>> also sets NoAccel on and X should use the FB device
> Tried this.  GDM starts fine in Xen and I can log in, but wow slow.  Now
> there's no reference to any GPU channel being opened in my X log.
The problem may be due to the initial AGP-memory allocation setting
up the wrong flags. And the older AGP cards seem to work differently
from the newer PCI/E ones.

Until someone resolves the agp issue, I guess your best choice
is to remove the ShadowFB option in the conf file and not install the dri
package (nouveau_dri.so and swrast_dri.so) in the AGP systems. That
means you will have 2D-accel but no glx (3D-accel).

Xen-devel mailing list