http://bugzilla.novell.com/show_bug.cgi?id=997464 Bug ID: 997464 Summary: radeon fails to initialize some DisplayPort monitors Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: openSUSE 42.1 Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-maintainers@forge.provo.novell.com Reporter: reg@seowebsales.com QA Contact: qa-bugs@suse.de Found By: --- Blocker: --- Created attachment 691006 --> http://bugzilla.novell.com/attachment.cgi?id=691006&action=edit Logs to compare all screens properly booted to some not Here's everything I have been able to determine about this issue but first the hardware setup: My graphics card is "HD 5870 Eyefinity 6" which has 6 DisplayPorts. 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 running 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 Focusing on kernel-4.7.2 the kernel would only turn on the first two displays. 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=0 to the boot makes things better but doesn't fix the issue completely. With that settings sometimes I'll get all 6 boot properly, more often I'll get 5 out of six boot properly and one doesn't. 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 information as needed. I really want to get this problem solved and I'll do whatever I can to help. 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/ screens-0-4-good-5-bad_kernel-4.7.2-1-default_logo.nologo-radeon.audio=0-debug-debug_objects_dmsg.txt screens-0-5-good_kernel-4.7.2-1-default_logo.nologo-radeon.audio=0-debug-debug_objects_dmsg.txt Anybody who wanted to also gather comprehensive information for the developers 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 =================== . +-- logs +-- filtered-drm +-- timing-stripped +-- filtered-drm This structure is as follows: . = 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 ====== 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 =================== 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 ====================== The above raw Log files with the timing at the beginning of each line removed. This makes using diff programs easier. 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 =================================== 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. Again, makes it easier to see what's relevant. If you want to know exactly how this was done you can look at the script ./gather-info-for-diagnostics.sh. Scripts ======= ./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 consistently 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. File Names ========== File names take the form of: <what happened to the screens at boot>_<partial command line when booting the kernel>_<the file name>.txt E.g. The file: screens-0-4-good-5-bad_kernel-4.7.2-1-default_logo.nologo-radeon.audio=0-debug-debug_objects_dmsg.txt can be broken down to: screens-0-4-good-5-bad = The first 5 of the 6 screens came on as they should during boot but the 6th one (number 5) did not. kernel-4.7.2-1-default_logo.nologo-radeon.audio=0-debug-debug_objects = shows most of the boot command line dmsg = A key indicating the file contents, from dmesg in this case .txt = That is is a text file If the file starts off with something like this: 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. Misc ==== I saw an issue on kernel.org that I reported the details to and I am not sure if since I use openSUSE all time if I should be reporting here letting you push upstream if you don't think you should tackle it or if I should report directly to kernel.org. In any case, if this is the wrong place to report this issue please let me know. -- You are receiving this mail because: You are on the CC list for the bug.