Bug 56435 - [Evergreen+R600 multiseat] KMS only works on one card at a time---two X servers for multiseat and only one works.
Summary: [Evergreen+R600 multiseat] KMS only works on one card at a time---two X serve...
Status: RESOLVED MOVED
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/Radeon (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: xf86-video-ati maintainers
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-10-26 16:25 UTC by skomorokh
Modified: 2019-11-19 07:38 UTC (History)
6 users (show)

See Also:
i915 platform:
i915 features:


Attachments
xorg.seat1.conf (399 bytes, text/plain)
2012-10-26 16:25 UTC, skomorokh
no flags Details
xorg.seat2.conf (399 bytes, text/plain)
2012-10-26 16:26 UTC, skomorokh
no flags Details
5770 (seat1) failing in multiseat config (19.44 KB, text/plain)
2012-10-26 16:28 UTC, skomorokh
no flags Details
4350 (seat2) succeeding in other server while seat1 is failing (xorg log) (76.24 KB, text/plain)
2012-10-26 16:29 UTC, skomorokh
no flags Details
5770 succeeding on seat1 when started via startx (100.81 KB, text/plain)
2012-10-26 16:29 UTC, skomorokh
no flags Details

Description skomorokh 2012-10-26 16:25:51 UTC
Created attachment 69121 [details]
xorg.seat1.conf

Trying to port a long functioning fglrx multiseat setup to use the radeon driver as the X.org 1.13.0 in Ubuntu 12.10 is incompatible with the old fglrx and the new fglrx is incompatible with my R600 (4350). 

What happens is both cards/screens successfully change modes for the graphical console. However, when KDM comes up, only seat2 (4350) enters X. seat1 (5770) fails with a KMS error.  

[    60.389] (EE) RADEON(0): [drm] failed to set drm interface version.
[    60.389] (EE) RADEON(0): Kernel modesetting setup failed

If I exit X and restart (sans xorg conf), the 5770 works fine (of course the second server is not started).

I am launching the two X servers via KDM thusly (note shared vts):

ServerArgsLocal=-config xorg.seat1.conf -nolisten tcp -isolateDevice PCI:2:0:0
ServerArgsLocal=-config xorg.seat2.conf -nolisten tcp -isolateDevice PCI:1:0:0 -sharevts -novtswitch


I have udev rules tagging the input devices and those xorg.seat*.conf files (attached) use MatchTag to work with that. Their Device sections look like: 

Section "Device"
        Identifier  "Seat1"
        Driver      "radeon"
        BusID       "PCI:2:0:0"
        Option      "Int10" "off"
EndSection
Comment 1 skomorokh 2012-10-26 16:26:27 UTC
Created attachment 69122 [details]
xorg.seat2.conf
Comment 2 skomorokh 2012-10-26 16:28:05 UTC
Created attachment 69123 [details]
5770 (seat1) failing in multiseat config
Comment 3 skomorokh 2012-10-26 16:29:12 UTC
Created attachment 69124 [details]
4350 (seat2) succeeding in other server while seat1 is failing (xorg log)
Comment 4 skomorokh 2012-10-26 16:29:43 UTC
Created attachment 69125 [details]
5770 succeeding on seat1 when started via startx
Comment 5 Jerome Glisse 2012-10-26 16:39:58 UTC
Does it works if you boot in level 3, login remotely and launch both Xserver :

Xorg -config xorg.seat1.conf -nolisten tcp -isolateDevice PCI:2:0:0 &
Xorg -config xorg.seat2.conf -nolisten tcp -isolateDevice PCI:2:0:0 &
Comment 6 skomorokh 2012-10-26 20:18:48 UTC
Gave that a try. seat1 came up, seat2 gave the exact same drm interface version / KMS error as seat1 did when called by KDM. Interesting that KDM seems to be calling them in reverse order.

Well, sort of did that: Ubuntu seems to have no distinction between runlevels anymore, I stopped the KDM service and then SSH'd in from my laptop. 

Also needed to specify a new display by adding :1 to the second command. And 
PCI:1:0:0 for seat2.
Comment 7 Alex Deucher 2012-10-26 20:22:35 UTC
make sure you use the right pci ids.  should be:
Xorg -config xorg.seat1.conf -nolisten tcp -isolateDevice PCI:2:0:0 &
Xorg -config xorg.seat2.conf -nolisten tcp -isolateDevice PCI:1:0:0 &
Comment 8 skomorokh 2012-10-26 20:29:23 UTC
(In reply to comment #7)
> make sure you use the right pci ids.  should be:
> Xorg -config xorg.seat1.conf -nolisten tcp -isolateDevice PCI:2:0:0 &
> Xorg -config xorg.seat2.conf -nolisten tcp -isolateDevice PCI:1:0:0 &

Yup, probably posted comment #6 where I mentioned that while you were writing yours :)


For clarity, I used:

Xorg -config xorg.seat1.conf -nolisten tcp -isolateDevice PCI:2:0:0 &
Xorg :1 -config xorg.seat2.conf -nolisten tcp -isolateDevice PCI:1:0:0 -sharevts -novtswitch &


In that configuration, seat2 failed. With KDM, seat1 failed. Both failures were:
 
[    60.389] (EE) RADEON(0): [drm] failed to set drm interface version.
[    60.389] (EE) RADEON(0): Kernel modesetting setup failed
Comment 9 skomorokh 2012-10-27 23:42:02 UTC
Hm, I'm finding that this same configuration works fine with the radeon driver in X.org 1.12.3 from this PPA:

https://launchpad.net/~makson96/+archive/fglrx

Not sure what has changed but I'd definitely like to help in any way I can so I can continue with multi-seat in future X.org versions.
Comment 10 Alexey 2012-11-21 14:27:21 UTC
I have same bug.

[X-:0-Core]
ServerArgsLocal=-nolisten tcp -config /etc/X11/4250.conf -sharevts -novtswitch -isolateDevice PCI:1:5:0

[X-:1-Core]
ServerArgsLocal=-nolisten tcp -config /etc/X11/6930.conf -isolateDevice PCI:2:0:0

4250 fails to start

if this way

[X-:0-Core]
ServerArgsLocal=-nolisten tcp -config /etc/X11/6930.conf -isolateDevice PCI:2:0:0

[X-:1-Core]
ServerArgsLocal=-nolisten tcp -config /etc/X11/4250.conf -sharevts -novtswitch -isolateDevice PCI:1:5:0

6930 fails to start

Each seat individually works fine

Also with this PPA works perfectly

https://launchpad.net/~makson96/+archive/fglrx
Comment 11 Dushan Tcholich 2012-11-27 17:12:07 UTC
I have same problem using Gentoo, but I had working setup with 1.12, but got the exact same problems when upgraded to 1.13
Everything is same with kernels from 2.6.39 to 3.6.6
Cards are Radeon HD3450 and HD5430

Only the first server starts, and 2nd one fails with:
(EE) RADEON(0): [drm] failed to set drm interface version.
(EE) RADEON(0): Kernel modesetting setup failed

I'm using GDM and custom.conf is:
[servers]
0=Standard1
1=Standard0

[server-Standard0]
name=Standard server 0
command=/usr/bin/X1 -config xorg.conf.1 -nolisten tcp -layout seat1 -novtswitch -isolateDevice PCI:3:0:0 -sharevts -xinerama -keeptty
flexible=false

[server-Standard1]
name=Standard server 1
command=/usr/bin/X0 -config xorg.conf.0 -nolisten tcp -layout seat0 -novtswitch -isolateDevice PCI:1:0:0 -xinerama -keeptty
flexible=false

xorg.conf.1 has:

Section "ServerFlags"
    Option         "DefaultServerLayout" "seat1"
    Option         "AllowMouseOpenFail"  "true"
    Option         "AutoAddDevices"      "false"
    Option      "AutoEnableDevices"     "false"
    Option         "DontVTSwitch" "yes"
    Option         "DontZap" "yes"
EndSection

Section "Device"
    Identifier     "Device1"
    BoardName      "ATI Radeon3450"
    Driver         "radeon"
    BusID          "PCI:3:0:0"
    Option         "AccelMethod" "EXA"
        Option      "ProbeAllGpus" "false"
    Option      "Monitor-DVI-1" "Monitor1"
EndSection

Thanks
Dushan
Comment 12 Dushan Tcholich 2012-11-28 21:33:24 UTC
I solved the problem for me with help from gentoo devs ( https://bugs.gentoo.org/show_bug.cgi?id=444964 ) by downgrading to xf86-video-ati-6.14.6-r1
Comment 13 Alexey 2012-11-29 09:53:59 UTC
Downgrading works for me too, but it isn't solution, right?
Comment 14 Goulou 2013-01-21 21:46:37 UTC
I can confirm the same bug with Fedora 18, using a dual seat setup ([drm] failed to set drm interface version.)

Unfortunately, I'm not sure I can downgrade to 6.14 easily (if anybody has an hint, I'll be happy to hear it!).

So as of now, my wife has a fully accelerated desktop, and I inherited the slow one...
Comment 15 Johan 2013-02-23 19:03:11 UTC
Hi
I have been using this multiseat with Ubuntu precice. I have since upgraded to Quantal and now raring since after the first upgrade was not working as expected because of this.
I have tried to downgrade to xserver-xorg-video-ati-6.14.99~git20111219.aacbd629 but I fail to build it. Disableing XAA for the missing xaa.h works but then I get this.
../../src/radeon_driver.c:6490:5: warning: passing argument 1 of 'pScreen->CloseScreen' makes pointer from integer without a cast [enabled by default]
../../src/radeon_driver.c:6490:5: note: expected 'ScreenPtr' but argument is of type 'int'
../../src/radeon_driver.c:6490:5: error: too many arguments to function 'pScreen->CloseScreen'

I hope for a patch in the current version.
-- 
Johan
Comment 16 Johan 2013-03-02 12:23:50 UTC
Hi
This was fixed for me by adding the AutoAddGPU false option in /etc/X11/xorg.conf

Section "ServerFlags"
 Option  "AutoAddGPU" "false"

This is atleast for me still undocomented in man xorg.conf

Please report if you have this option set and get the same error.
-- 
Johan
Comment 17 Jan De Luyck 2013-10-02 09:13:33 UTC
I bumped into this problem after upgrading my Debian installation (Sid) to the latest packages, which included the entire Xorg stack.

Adding "AutoAddGPU" "false" made the second interface initialise again.
Comment 18 Jan De Luyck 2013-10-02 09:14:19 UTC
Hardware involved:

01:05.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RS780 [Radeon HD 3200]
02:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RV770 [Radeon HD 4850]
Comment 19 Dushan Tcholich 2013-10-21 18:40:22 UTC
I still have the same problem with server 1.13 and 1.14, could it be related to this bug (DRM hotplug does not obey -isolateDevice): https://bugs.freedesktop.org/show_bug.cgi?id=63576

When I change the order of devices that get started, always the second one fails.
Comment 20 Martin Peres 2019-11-19 07:38:14 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-ati/issues/47.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.