Created attachment 126301 [details]
Logs to compare all screens properly booted to some not
It took a mistake or two but I have been directed that this is the place to
report this issue. I believe I am in a unique position to help with Display=
Port
issues (and want to do so) because I have been able to generate both working
and non-working logs and because I have a significant quantity of DisplayPo=
rts
on my system, 6 in total. Also, I put a wealth of information together
(automated for completeness and consistency) that should help the developme=
nt
team nail down the cause of this issue.
Here's everything I have been able to determine but first the hardware setu=
p:
My graphics card is "HD 5870 Eyefinity 6" which has 6 DisplayPort=
s. I have them
setup in a grid of 3 across by 2 down. Each display is at a resolution of
2560x1440 creating a total work area of 7680x2880 in a Xinerama setup runni=
ng
on the KDE4 desktop.
I currently have 3 kernels in my grub list which are:
kernel-3.16.7
kernel-4.7.0
kernel-4.7.2
These are all with suse's Tumbleweed however kernel-3.16.7 came with openSU=
SE
13.2.
I have no evidence that my problem is related to so many screens of
DisplayPorts but it does allow me to see more variations of the problem than
most do which helps pinpoint what the real problem is (hopefully!)
Focusing on kernel-4.7.2 the kernel would only turn on the first two displa=
ys.
That happens during boot long before Xorg gets loaded.
In Xorg the behavior is a little strange when it gets DisplayPorts off from=
the
kernel. Xorg will acknowledge all 6 displays but it is not able to turn on =
any
that are initially off when the kernel was handling them. E.g.: the last 4
monitors in the case of the 4.x kernels.
The upshot is that when I go to the multidisplay setup part of KDE all 6
displays are showing as active even though only the first two are turned on=
in
reality. If I disable and re-enable the displays turned off, they don't turn
on. If I use xrandr to turn them on, no dice. That is, if they are off when=
the
kernel was handling them they are off for good, nothing in Xorg or KDE can
change it that I have found.
That said, adding radeon.audio=3D0 to the boot makes things better but does=
n't
fix the issue completely. With that settings sometimes I'll get all 6 boot
good, more often I'll get 5 out of six boot good and one bad. Usually, the =
last
one (DisplayPort 5) is the one that fails when one does, however, not alway=
s.
I went to the trouble to write a script to gather information and I think I=
got
enough to show where things are going wrong. At least enough to show a
difference between a good and bad boot and I will help with more informatio=
n as
needed. I really want to get this problem solved and I'll do whatever I can=
to
help.=20
In the tarred file, to see what's different between a good and bad boot all=
you
have to do is a diff on the files:
./logs/timing-stripped/filtered-drm/
=20=20=20=20=20=20=20
screens-0-4-good-5-bad_kernel-4.7.2-1-default_logo.nologo-radeon.audio=3D0-=
debug-debug_objects_dmsg.txt
=20=20=20=20=20=20=20
screens-0-5-good_kernel-4.7.2-1-default_logo.nologo-radeon.audio=3D0-debug-=
debug_objects_dmsg.txt
Anybody who wanted to also gather comprehensive information for the develop=
ers
could take the file ./gather-info-for-diagnostics.sh in the tarred file and
modify as needed for their own system.
That said, below explains in detail what's in the tarred compressed file.
Directory structure
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
.
+-- logs
+-- filtered-drm
+-- timing-stripped
+-- filtered-drm
This structure is as follows:
.=20
=3D
The script that creates the log files and script to turn on any screens
that are off during boot (more on this one later).
./logs
=3D=3D=3D=3D=3D=3D
The raw log files the script gathered which include:
dmsg.txt - from dmesg
proc-cmdline.txt - from /proc/cmdline
module-kernel-parameters.txt - from
/sys/module/kernel/parameters/*
module-processor-parameters.txt - from
/sys/module/processor/parameters/*
sys-module-radeon-parameters.txt - from
/sys/module/radeon/parameters/*
Xorg.0.log.txt - from /var/log/Xorg.0.log
./logs/filtered-drm
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Some of the above raw log files with lines that do not contain radeon
information removed - makes it easier to see what's relevant. If you want to
know exactly how the lines were filtered you can look at the script
./gather-info-for-diagnostics.sh.
./logs/timing-stripped
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
The above raw log files with the timing at the beginning of each line
removed. This makes using diff programs easier (I use meld on Linux). If you
want to know exactly how this was done you can look at the script
./gather-info-for-diagnostics.sh.
./logs/timing-stripped/filtered-drm
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Some of the above raw log files with the timing at the beginning of each
line removed and lines that do not contain radeon information removed. Agai=
n,
makes it easier to see what's relevant. If you want to know exactly how th=
is
was done you can look at the script ./gather-info-for-diagnostics.sh.
Scripts
=3D=3D=3D=3D=3D=3D=3D
./gather-info-for-diagnostics.sh
--------------------------------
Does all the heavy lifting in gathering the info.
./display-on.sh
---------------
This was a curious discovery and may make fixing the issue easier. This is
because I found when the script was like this:
xrandr --output DisplayPort-${1} --mode 1920x1080
xrandr --output DisplayPort-${1} --mode 2560x1440
it sometimes it would turn the display on but others it would turn it off. =
To
consistantly turn the display on I had to change it to this:
xrandr --output DisplayPort-${1} --mode 1920x1080
sleep 5
xrandr --output DisplayPort-${1} --mode 2560x1440
suggesting there might be a timing problem that needs to be addressed. Even
though running this script can turn the display on that was erroneously off
during boot the display will turn itself back off after a few seconds or so=
so
it's not a usable workaround. I guess there is some status flag during boot=
in
the kernel that ultimately can't be changed or overridden that eventually
reasserts itself.
Update: It may not be that the 5 second delay solved the issue. It may be t=
hat
just running it again was the solution. Perhaps the first time some cache g=
ot
cleared, I'm not really sure, some experimenting is in need on this one.
File Names
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
File names take the form of:
<what happened to the screens at boot>_<partial command line w=
hen booting
the kernel>_<the file name>.txt
E.g. The file:
=20=20=20=20=20=20=20
screens-0-4-good-5-bad_kernel-4.7.2-1-default_logo.nologo-radeon.audio=3D0-=
debug-debug_objects_dmsg.txt
can be broken down to:
screens-0-4-good-5-bad =3D The first 5 of the 6 screens came o=
n as
they should during boot but the 6th one (number 5) did not.
kernel-4.7.2-1-default_logo.nologo-radeon.audio=3D0-debug-debug_obj=
ects
=3D shows most of the boot command line
dmsg =3D A key indicating the file contents,=
from
dmesg in this case
.txt =3D That this is a text file
If the file starts off with something like this:=20
screens-0-5-good-after-5-fixed-with_display-on.sh it means after booting and
logging in I ran the script ./display-on.sh to turn on the display and then
gathered all the log information. I will have gathered the log information
prior to running the script as well so you will also see files prefixed with
just screens-0-5-good in such a case.
Let me know what else I can do to help.