From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1J152y-0007NF-Tc for garchives@archives.gentoo.org; Sat, 08 Dec 2007 19:09:09 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.14.2/8.14.0) with SMTP id lB8J7GZa016720; Sat, 8 Dec 2007 19:07:16 GMT Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.189]) by robin.gentoo.org (8.14.2/8.14.0) with ESMTP id lB8J7FSM016715 for ; Sat, 8 Dec 2007 19:07:15 GMT Received: by mu-out-0910.google.com with SMTP id i2so1888759mue for ; Sat, 08 Dec 2007 11:07:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; bh=cUoYtUk7T6T/kzJH81qhX59lQooe4cwgNSUeHYH8XDY=; b=UPl8Io5v+HZ4bzbrnPGDDAsLrX+5t/TW2SoodhtbR2i8LOl9veSSh0eTsty30OPTbMrBbMbyKgfnu3TWQrYj1ZvPO70AP1ldaJdei0pI5LXeNrpg6dtwPUDMRU07AISENvEFMZUU2XOwxX6cUG9Wx8ZjV7di+NzuCFdHqcnHcv0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=PsXCqSjWxtLMl3Y77owuS05ADFM97rZW0PvM3Stu0XG31BFnbEx1zX974hNp5nx+/VS9/j2OVIfleFM0EoZA7d9lPHVXF2F90buXBOKXkboxGc5k43HdprE/KHAflSeG7qCIeQqFGz11i0xuHyfE+uEBKILcjkfhXZsCNnFN7SM= Received: by 10.82.183.19 with SMTP id g19mr8974582buf.1197140835114; Sat, 08 Dec 2007 11:07:15 -0800 (PST) Received: by 10.82.141.15 with HTTP; Sat, 8 Dec 2007 11:07:15 -0800 (PST) Message-ID: Date: Sat, 8 Dec 2007 19:07:15 +0000 From: Beso To: gentoo-amd64@lists.gentoo.org Subject: Re: [gentoo-amd64] Gentoo AMD64 + Xen + Ati drivers In-Reply-To: <475AE211.4070604@laposte.net> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-amd64@gentoo.org Reply-to: gentoo-amd64@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_17683_6954368.1197140835107" References: <47567E7F.7080806@laposte.net> <475AE211.4070604@laposte.net> X-Archives-Salt: a7e41d59-2823-4b06-abce-62e6506bc9dd X-Archives-Hash: bff17925e4dcedc105e69aba05adac0c ------=_Part_17683_6954368.1197140835107 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline what i could tell you is that xen is a little behind with the sources, but still if configured in the right way there should be no problem in running = a box. you just have to remember that with xen you'll need a "base" system, then another system to run on this base with reduced priviledges and assigned stuff. so you'll just need a base gentoo (stage3 should be fine), then you should configure xen to have another stage3 with installed apps. the xen problem is that you'll need 2 linuxes to run one linux. but you'll be allowed to assign processors fragments or ram portions in the way you like. if you don't really need xen (you would run at least 2 different systems like using one linux i686 one amd64 or one linux and one windows - which should run well since you have vt) i think that using it would be a waste of time. also there are tools that let you install windows in boxes, like vmware and such (they're very good and fast and don't put you in the situation to use xen when xen is way back with kernel support and a lot of the new stuff in new pcs is supported only from the 2.6.21 or later kernel like the jmicron controller used in asus mobos). so my advice is avoid usin= g xen unless it is really, really and i mean really necessary (you'll need 2 systems and a lot of configuration to run a single linux box that is slower than a native one). for the radeon driver, always use the ~amd64/~x86. always, since the driver is updated every month and has new things. for example the latest portage 8.433 has aiglx support support for the latest xorg and xorg-server (even i= f compiz won't work with xorg-server-1.4) and it has a great performance boost. also the new radeon has a hidden option to be added into the device section for enabling a render: Option "TexturedXrender" "true" it seems that this has a performance boost with rendering. for ati, you'll also have to control that you have the following files in /usr/lib/ libGL.so.1, libGL.so.1.2. if one of them is missing create a symlink to the other libGL.so.x. this is due to a soname bug present in the latest fglrx releases. also be aware that there's a memory leak bug and apps like glxgears, amarok, firefox or others that use opengl would continue to suck out system memory. stay tuned to see if this happens and restart xorg when the system ram has reached a critical limit like 85-90%. or you may want to try the xf86 ati drivers for r500 (your chipset) because airlied, who is the main dev for the r500/600 radeon driver now works for red hat, has added some cool features like radeon modesetting and other stuff in the latest releases and you should be able to get a good working driver. you'll just have to add radeon support to xorg and use the radeon driver from ~amd64/~x86 branch. with ati these days is almost necessary to use this branch since the new releases add a lot of new features and fixes due to the recent amd/ati releasing specs and helping devs. i also would sa= y you to remove the fbdev and all framebuffer ati modules or so from kernel since they're buggy and won't work correctly. also fb is useless if you use vesa or other stuff. is you use the fglrx then you'll also need to add the following stuff to th= e device section of your xorg.conf: Option "RenderAccel" "true" <--- needed for rendering stuff: force= s sw rendering where hw doesn't work. Option "AllowGLXWithComposite" "true" <--- needed for compiz/beryl Option "HWCursor" "On" <---- needed to fix a bug with the mouse cursor Option "OpenGLOverlay" "off" <---- disables opengl overlay and doesn't work with Xv enabled Option "VideoOverlay" "on" <--- enables Xv overlay doesn't work with opengloverlay enabled Option "no_dri" "no" <---- use dri Option "UseInternalAGPGART" "no" <---- this is needed for some agpgart issues Option "FSAAEnable" "no" <---- disables fsaa since it is buggy on linux Option "BlockSignalsOnLock" "on" <----- needed to a have a stable driver Option "Capabilities" "0x00000000" <---- set capabilities to defaul= t since some cards are buggy with non default capabilities Option "mtrr" "off" <---- disables mtrr Option "XAANoOffscreenPixmaps" "true" <---- needed to fix the watermark issue of the latest fglrx releases Option "UseFastTLS" "0" <---- if you use wine don't set this to higher than 1. also for a working compiz you'll need this section: Section "Extensions" Option "DAMAGE" "true" Option "RENDER" "true" Option "Composite" "Enable" EndSection this is the working configuration for a fglrx running with compiz. if you experience issue with compiz then set the compiz setting from "texturefrompixmap" rendering to "force copy". 2007/12/8, Florent Ouchet : > > Florent Ouchet a =E9crit : > > I experienced some problems with the following combination of software: > > - xen-sources 2.6.20-r6 > > - xen-tools 3.1.2 > > - ati-drivers 8.40.4 > > - linux 2.6.20 > > - xorg-server 1.3.0.0-r2 (build with support for fbdev, vesa and fglrx) > > > > The system is a Dom0 of a paravirtualized system: > > - Core 2 Duo 2.4GHz (vT enabled) > > - 2GB RAM > > - ATI Radeon x1300 video card > > > > Is anyone running such a configuration with success? I have to stay > > with the vesa driver without hardware acceleration. > > No one managed to get such a config running with optimal performances? :( > > > -- > gentoo-amd64@gentoo.org mailing list > > --=20 dott. ing. beso ------=_Part_17683_6954368.1197140835107 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline what i could tell you is that xen is a little behind with the sources, but = still if configured in the right way there should be no problem in running = a box. you just have to remember that with xen you'll need a "base= " system, then another system to run on this base with reduced privile= dges and assigned stuff. so you'll just need a base gentoo (stage3 shou= ld be fine), then you should configure xen to have another stage3 with inst= alled apps. the xen problem is that you'll need 2 linuxes to run one li= nux. but you'll be allowed to assign processors fragments or ram portio= ns in the way you like. if you don't really need xen (you would run at = least 2 different systems like using one linux i686 one amd64 or one linux = and one windows - which should run well since you have vt) i think that usi= ng it would be a waste of time. also there are tools that let you install w= indows in boxes, like vmware and such (they're very good and fast and d= on't put you in the situation to use xen when xen is way back with kern= el support and a lot of the new stuff in new pcs is supported only from the= =20 2.6.21 or later kernel like the jmicron controller used in asus mobos). so = my advice is avoid using xen unless it is really, really and i mean really = necessary (you'll need 2 systems and a lot of configuration to run a si= ngle linux box that is slower than a native one).

for the radeon driver, always use the ~amd64/~x86. always, since th= e driver is updated every month and has new things. for example the latest = portage 8.433 has aiglx support support for the latest xorg and xorg-server= (even if compiz won't work with=20 xorg-server-1.4) and it has a great performance boost. also the new radeon = has a hidden option to be added into the device section for enabling a rend= er:
Option "TexturedXrender" "true"
it seems that= this has a performance boost with rendering. for ati, you'll also have= to control that you have the following files in /usr/lib/
libGL.so.1, libGL.so.1.2. if one of them is missing create a symlink to= the other libGL.so.x. this is due to a soname bug present in the latest fg= lrx releases. also be aware that there's a memory leak bug and apps lik= e glxgears, amarok, firefox or others that use opengl would continue to suc= k out system memory. stay tuned to see if this happens and restart xorg whe= n the system ram has reached a critical limit like 85-90%.
or you may want to try the xf86 ati drivers for r500 (your chipset) bec= ause airlied, who is the main dev for the r500/600 radeon driver now works = for red hat, has added some cool features like radeon modesetting and other= stuff in the latest releases and you should be able to get a good working = driver. you'll just have to add radeon support to xorg and use the rade= on driver from ~amd64/~x86 branch. with ati these days is almost necessary = to use this branch since the new releases add a lot of new features and fix= es due to the recent amd/ati releasing specs and helping devs. i also would= say you to remove the fbdev and all framebuffer ati modules or so from ker= nel since they're buggy and won't work correctly. also fb is useles= s if you use vesa or other stuff.
is you use the fglrx then you'll also need to add the following stu= ff to the device section of your xorg.conf:
  Option  &nb= sp;     "RenderAccel" "true" <--= - needed for rendering stuff: forces sw rendering where hw doesn't work= .
  Option        "AllowGLXW= ithComposite" "true" <--- needed for compiz/beryl
&nbs= p; Option        "HWCursor" &q= uot;On" <---- needed to fix a bug with the mouse cursor
  O= ption       "OpenGLOverlay" "o= ff" <---- disables opengl overlay and doesn't work with Xv enab= led
  Option        "VideoOver= lay" "on" <--- enables Xv overlay doesn't work with o= pengloverlay enabled
  Option       &= quot;no_dri" "no" <---- use dri
  Option &nb= sp;     "UseInternalAGPGART" "no" &= lt;---- this is needed for some agpgart issues=20
  Option       "FSAAEnable"= ; "no" <---- disables fsaa since it is buggy on linux
 = ; Option       "BlockSignalsOnLock"= "on" <----- needed to a have a stable driver
  Option=        "Capabilities" "0x00000= 000" <---- set capabilities to default since some cards are buggy w= ith non default capabilities
  Option       "mtrr" &quo= t;off" <---- disables mtrr
  Option    =     "XAANoOffscreenPixmaps" "true" <-= --- needed to fix the watermark issue of the latest fglrx releases
 = ; Option       "UseFastTLS" "0= " <---- if you use wine don't set this to higher than 1.

also for a working compiz you'll need this section:

Sect= ion "Extensions"
  Option     &n= bsp;  "DAMAGE" "true"
  Option  =       "RENDER" "true"
 = ; Option        "Composite" &q= uot;Enable"
EndSection

this is the working configuration for a fglrx running= with compiz. if you experience issue with compiz then set the compiz setti= ng from "texturefrompixmap" rendering to "force copy".

2007/12/8, Florent Ouchet <ouchet.florent@laposte.net>= ;:
Florent Ouchet a =E9crit :
> I experienced some problems with the fol= lowing combination of software:
> - xen-sources 2.6.20-r6
> - x= en-tools 3.1.2
> - ati-drivers 8.40.4
> - linux 2.6.20
> = - xorg-server=20 1.3.0.0-r2 (build with support for fbdev, vesa and fglrx)
>
> T= he system is a Dom0 of a paravirtualized system:
> - Core 2 Duo 2.4GH= z (vT enabled)
> - 2GB RAM
> - ATI Radeon x1300 video card
>
> Is anyone running such a configuration with success? I have to= stay
> with the vesa driver without hardware acceleration.

No= one managed to get such a config running with optimal performances? :(


--
gentoo-amd64@g= entoo.org mailing list



=
--
dott. ing. beso ------=_Part_17683_6954368.1197140835107-- -- gentoo-amd64@gentoo.org mailing list