fglrx multiseat crash

[bridgman]

My points were that :

a) multi-GPU support was only added to the consumer drivers quite recently (in the last couple of months), so your chances of success are best on the configurations we tested first (ie matched cards). Over time, this should be less of an issue.

b) you are basically setting up the driver the same way as the NVidia card even though the ATI driver uses a different mechanism for managing configuration changes. The ATI driver uses the aticonfig command in most cases, and stores the resulting config info in amdpcsdb, not in the conf file. Simply copying and tweaking an NVidia config file is not likely to work.

I don't think using RandR or the open source drivers will work for you today, although it wouldn't hurt to look up the posts related to turning RandR off in fglrx.

Seems Randr is applicable when doing either a Xephyr or XGL multiseat - with individual x-servers the gpu's don't "see" each other as active, nor do they share a framebuffer..

For a single GPU, yes. My point is that most of the devs have said you can't use RandR with multiple GPUs today.

[c1981]

Right, now I understand why fiddling with the xorg.conf helped little to nothing..

Do you know which aticonfig options might work?

[bridgman]

I haven't played with aticonfig much myself (my role here is related to the open source drivers) but will see what I can find.

My guess would be that deleting the amdpcsdb file (not the backup, just the active copy) then running aticonfig --initial --adapters=all before starting X might be a good place to start.

[c1981]

Thanks, if you could find a helpful post I'd be very grateful indeed.

I tried the aticonfig all adapters option a few days back, haven't tried deleting the amdpcsdb file first yet..

[CMorrow]

Successful with Multiseat, no DPMS

Using the Kubuntu Jaunty x64 release candidate, I successfully setup and ran a multiseat setup using a Radeon 4850 and a Radeon 3850. I found the key to be minimal config (as few extra options as possible, forcing Xorg to defaults).

The biggest initial issue I had was that my 3850 kept hopping device IDs between reboots. It couldn't decide whether to settle on PCI:3:0:0 or PCI:4:0:0, so I was constantly modifying my Xorg.conf for the id-du-jour. If the second card wasn't initialized (due to wrong ID), the whole system would hang as soon as the password was entered in KDM (hard lock) in the first session.

When it did work, it worked pretty well. Just for kicks, I played a few rounds of Unreal Tournament 2004 with my daughter using seat0 and seat1. Performance was stellar.

The one thing that really killed me about it was that no matter what, I could not get DPMS to work. xset dpms options would cause the monitor to blank (black screen), but the backlight stayed on. vbetool was the only way to get the monitor to actually enter DPMS (and only on seat0).

I'm really not looking to keep 2 or 4 monitors on 24/7. If I can't figure out a fix, I'm going to start looking for different hardware.

[c1981]

I've tried Debian Lenny, OpenSuse 11.1 and Ubuntu Hardy Heron; tried
GDM, KDM, XDM; both with minimal xorg.conf and the one posted at the beginning of this thread - with varying degrees of success.

The xorg.conf I posted, allows DPMS to work on my system, but it only works 1 out of 10 boots. The crash always happens while loading the display manager - crashing way before a password can be entered.

The most succesful way I've set it up to now is by doing away with the display manager altogether and using a bash script for each user. Luckily, PCI id's aren't shifting on my system.

Another way that worked fairly well was doing a multi-vendor setup, with each X instance having it's own library path - but a bit time consuming to maintain.

Personally, I've abandoned ATi for now. The drivers just aren't up to standard - which is rather disappointing. I'm keeping the 2 HD 3450 to check if things improve every once in a while - but for now Nvdia is the only stable way to go multiseat - it seems.

I use the system as follows:

Seat 0: Work / game seat
" 1: Living room media center
" 2: Bedroom media center
" 3: Work / game seat for my girlfriend

Using nvidia cards typical usage is: Quake 4 on 0, MythTV on 1 or 2, and a normal work desktop on 3. Never a glitch, perfect performance - it all works.

[CMorrow]

We actually have very similar hardware -

MSI K9A2
CPU X2 5000 BE
8 GB of RAM (1066 running at 800)

Are you running in 32-bit or with an amd64 kernel? I'm wondering if this DPMS bug I have is amd64 only.

I'm using different server layouts to launch rather than different xorg.conf files. Here is my (mostly working) xorg.conf:

# xorg.conf (X.Org X Window System server configuration file)
#

Section "Module"
EndSection

Section "ServerFlags"
# Disable ctrl alt backspace
# Option "DontZap"
# Xorg will otherwise not start if it can't find a mouse to use.
Option "AllowMouseOpenFail" "true"
# Disable xinerama
Option "Xinerama" "0"
# Option "OffTime" "10"
EndSection

Section "InputDevice"
Identifier "keyboard0"
Driver "evdev"
Option "Device" "/dev/input/by-id/usb-Microsoft_Natural__Ergonomic_Keyboard_4000-event-kbd"
Option "XkbModel" "evdev"
Option "XkbLayout" "us"
EndSection

Section "InputDevice"
Identifier "keyboard1"
Driver "evdev"
Option "Device" "/dev/input/by-id/usb-045e_Microsoft_Natural_Keyboard_Pro-event-kbd"
Option "XkbModel" "evdev"
Option "XkbLayout" "us"
EndSection

Section "InputDevice"
Identifier "mouse0"
Driver "evdev"
Option "Name" "Logitech USB Mouse"
Option "Device" "/dev/input/by-id/usb-Logitech_USB_Mouse-event-mouse"
EndSection

Section "InputDevice"
Identifier "mouse1"
Driver "evdev"
Option "Device" "/dev/input/by-id/usb-Logitech_USB-PS_2_Optical_Mouse-event-mouse"
EndSection

Section "Device"
Identifier "radeon4850-0"
Driver "fglrx"
BusId "PCI:1:0:0"
Option "DPMS" "on"
EndSection

Section "Device"
Identifier "radeon3850-0"
Driver "fglrx"
BusId "PCI:4:0:0"
Option "DPMS" "on"
EndSection

Section "Monitor"
Identifier "2343bwx"
Option "dpms"
EndSection

Section "Monitor"
Identifier "216bw"
Option "dpms"
EndSection

Section "Screen"
Identifier "screen0"
Device "radeon4850-0"
Monitor "2343bwx"
DefaultDepth 24

Subsection "Display"
Depth 24
EndSubsection
EndSection

Section "Screen"
Identifier "screen1"
Device "radeon3850-0"
Monitor "216bw"
DefaultDepth 24
Subsection "Display"
Depth 24
EndSubsection
EndSection

Section "ServerLayout"
Identifier "seat0"
Screen "screen0" 0 0
InputDevice "mouse0" "CorePointer"
InputDevice "keyboard0" "CoreKeyboard"
Option "DisableModInDev" "true"
Option "AutoAddDevices" "off"
Option "BlankTime" "2" # Blank the screen after 2 minutes (Fake)
Option "StandbyTime" "5" # Turn off screen after 5 minutes (DPMS)
Option "SuspendTime" "10" # Full suspend after 10 minutes
Option "OffTime" "15" # Turn off after 15 mins
Option "Xinerama" "false"
EndSection

Section "ServerLayout"
Identifier "seat1"
Screen "screen1" 0 0
InputDevice "mouse1" "CorePointer"
InputDevice "keyboard1" "CoreKeyboard"
Option "DisableModInDev" "true"
Option "AutoAddDevices" "off"
Option "BlankTime" "2" # Blank the screen after 2 minutes (Fake)
Option "StandbyTime" "5" # Turn off screen after 5 minutes (DPMS)
Option "SuspendTime" "10" # Full suspend after 10 minutes
Option "OffTime" "15" # Turn off after 15 mins
Option "Xinerama" "false"
EndSection


I then tacked the following on to my kdmrc file:

[X-:0-Core]
ClientLogFile=.xsession-errors
ServerArgsLocal=-nolisten tcp -layout seat0 -sharevts -novtswitch


[X-:1-Core]
ClientLogFile=.xsession-errors
ServerArgsLocal=-nolisten tcp -layout seat1 -sharevts -novtswitch

[c1981]

We do indeed have pretty much the same hardware - do you also have quircky USB behaviour now-and-then?

I'm also using 64-bit only environments - haven't used a 32-bit distro in quite a while..

In my experience using either layouts or seperate xorg.conf files works equally well; I do feel that KDM handles multiseat better though.

By the looks of your xorg.conf DPMS should indeed be working -
I tried a similar config with Debian. Could it be a BIOS setting instead? Perhaps you could try going back to factory defaults, rebooting and re-enter the configuration..?

[c1981]

Actually come to think of it - moving all of the commands to the [screen] section might also help - keeping the [monitor], [device] and Serverlayout sections minimal. I remember it solving a few issues in an opensuse setup i tried a while back.

[CMorrow]

Actually come to think of it - moving all of the commands to the [screen] section might also help - keeping the [monitor] and [device] sections minimal. I remember it solving a few issues in an opensuse setup i tried a while back.

I'll give that a shot. I've tried almost everything I can think of. I think part of it may be due to this:

cmorrow@MultiPC:~$ aticonfig --lsp
Error: POWERplay is not supported on your hardware.

But I honestly have no idea *why* Power management functions would be disabled (this on a reference design Sapphire 4850) running Catalyst 9.4.

I do have the USB quirkyness, but my understanding (and subsequent blame) fell on the fact that the K9A2 like most other early AM2+ boards uses the AMD SB600 southbridge which has some serious USB and SATA issues. There have been kernel patches written by AMD to avoid total lockup under load, but I think it may still involve USB devices pausing for some time, etc.

Newer AM2+ boards use the SB750 which fixes all the SB600 and SB700 issues.