[gentoo-amd64] Gentoo AMD64 + Xen + Ati drivers

[gentoo-amd64] Gentoo AMD64 + Xen + Ati drivers

[Florent Ouchet]

Hi all,

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.

First of all, the "fglrx" kernel module of ati-drivers refuse to be 
loaded because of an inexistent symbol (flush_tlb_page) in the kernel, 
this error is easily solved by patching 
/usr/src/linux/arch/x86_64/kernel/smp.c (note that this patch is applied 
to the i386 arch, why is it missing here? - worth a report to 
xensource). After recompiling the kernel and its modules, rebooting and 
emerging ati-drivers again the fglrx module can be loaded.

an export is missing on line 301:
-----------------------
void flush_tlb_page(struct vm_area_struct * vma, unsigned long va)
{ xen_invlpg_mask(&vma->vm_mm->cpu_vm_mask, va); }
+EXPORT_SYMBOL(flush_tlb_page);
void flush_tlb_all(void)
-----------------------

After doing this, the ati-drivers don't work as expected, running "Xorg 
-configure" raise an exception in the driver:

-----------------------
xenoutch / # Xorg -configure :1

X Window System Version 1.3.0
Release Date: 19 April 2007
X Protocol Version 11, Revision 0, Release 1.3
Build Operating System: UNKNOWN
Current Operating System: Linux xenoutch 2.6.20-xen-r6 #10 SMP Tue Dec 4 
14:55:28 CET 2007 x86_64
Build Date: 04 December 2007
        Before reporting problems, check http://wiki.x.org
        to make sure that you have the latest version.
Module Loader present
Markers: (--) probed, (**) from config file, (==) default setting,
        (++) from command line, (!!) notice, (II) informational,
        (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.1.log", Time: Wed Dec  5 11:22:43 2007
List of video drivers:
        fglrx
        fbdev
        vesa
        vga

Backtrace:
0: Xorg(xf86SigHandler+0x6d) [0x48f90e]
1: /lib/libc.so.6 [0x2b4d877c4680]
2: /lib/libc.so.6(memcpy+0x46) [0x2b4d8780a636]
3: /usr/lib64/xorg/modules/drivers//fglrx_drv.so(atiddxProbeMain+0xf1) 
[0x2b4d87e3a731]
4: Xorg(DoConfigure+0x1f6) [0x49d2e0]
5: Xorg(InitOutput+0x6a2) [0x465605]
6: Xorg(main+0x275) [0x439aca]
7: /lib/libc.so.6(__libc_start_main+0xf4) [0x2b4d877b1b74]
8: Xorg(FontFileCompleteXLFD+0x211) [0x439039]

Fatal server error:
Caught signal 11.  Server aborting

Aborted
xenoutch / #
--------------------------

Selecting "fglrx" in an existing /etc/X11/xorg.conf makes X server to 
freeze (and local display unusable), all tty cannot be reached, screen 
is black; the system can be rebooted via ssh.

Regards,

Florent

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Gentoo AMD64 + Xen + Ati drivers

[Florent Ouchet]

Florent Ouchet a écrit :
> 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

Re: [gentoo-amd64] Gentoo AMD64 + Xen + Ati drivers

[Beso]

[-- Attachment #1: Type: text/plain, Size: 5631 bytes --]

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 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 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 if
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 say
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 the
device section of your xorg.conf:
  Option        "RenderAccel" "true" <--- needed for rendering stuff: forces
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 default
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 <ouchet.florent@laposte.net>:
>
> Florent Ouchet a écrit :
> > 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
>
>


-- 
dott. ing. beso

[-- Attachment #2: Type: text/html, Size: 7122 bytes --]

Re: [gentoo-amd64] Gentoo AMD64 + Xen + Ati drivers

[Florent Ouchet]

Hello,

Thanks for these useful advises, I used VMWare for months (and then 
VirtualBox few months), I want to give Xen the same chance. The best 
option seems to be the installation of a second domain to locally handle 
display, IMO this configuration could be highly unstable if either Dom0 
or "Dom1" starts tripping.

I'll try to use flgrx drivers again on next time kernel-xen source get 
updated (current version if 2.6.20), I'll report back here; Two 
open-source drivers are available for radeon video cards:
 - xf86-video-ati is not able to drive my video card (no matching device)
 - I give a try to the new radeonhd driver which currently gives better 
performance than vesa legacy driver.

Best regards,

Florent


Beso a écrit :
> 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 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 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 if 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 say 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 the device section of your xorg.conf:
>   Option        "RenderAccel" "true" <--- needed for rendering stuff: 
> forces 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 
> default 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".
> -- 
> dott. ing. beso 


-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Gentoo AMD64 + Xen + Ati drivers

[Beso]

[-- Attachment #1: Type: text/plain, Size: 1445 bytes --]

this xf86-video-ati should have it work. see airlied blog
http://airlied.livejournal.com/ and google around xorg a little to have this
confirmed (thi should be on of the latest release 6.7.196-r1).
radeon-hd instead doesn't have 2d or 3d support, so you could only use it
for the eventual base system without xorg fancies for xen. i don't think
that for now it's an option for everyday use.
well, as for the domains, i'd say: let the base domain hanlde hw and bridge
it to the other domains. after that every single domain would be indipendent
from the other and so if one display goes mad you won't have problems with
the other one.

2007/12/9, Florent Ouchet <ouchet.florent@laposte.net>:
>
> Hello,
>
> Thanks for these useful advises, I used VMWare for months (and then
> VirtualBox few months), I want to give Xen the same chance. The best
> option seems to be the installation of a second domain to locally handle
> display, IMO this configuration could be highly unstable if either Dom0
> or "Dom1" starts tripping.
>
> I'll try to use flgrx drivers again on next time kernel-xen source get
> updated (current version if 2.6.20), I'll report back here; Two
> open-source drivers are available for radeon video cards:
> - xf86-video-ati is not able to drive my video card (no matching device)
> - I give a try to the new radeonhd driver which currently gives better
> performance than vesa legacy driver.
>
> Best regards,
>
> Florent
>
>

[-- Attachment #2: Type: text/html, Size: 1811 bytes --]