[Bug 100871] radeon fails to initialize one DisplayPort monitor

bugzilla-daemon at bugzilla.kernel.org bugzilla-daemon at bugzilla.kernel.org
Tue Sep 6 10:28:10 UTC 2016


https://bugzilla.kernel.org/show_bug.cgi?id=100871

Reg <reg at regproctor.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #231661|0                           |1
        is obsolete|                            |
 Attachment #231671|0                           |1
        is obsolete|                            |

--- Comment #14 from Reg <reg at regproctor.com> ---
Created attachment 232241
  --> https://bugzilla.kernel.org/attachment.cgi?id=232241&action=edit
Logs to compare all screens good on boot to some bad on boot

First I have to take one thing back, the radeon.audo=0 definitely makes a
difference and I am not so sure that radeon.apgmode=-1 helps anymore. That
said, things still go wrong. Because the biggest issue here seems to be a lack
of reproducibility and therefore it's almost impossible to track down I went to
the trouble to write a script to gather information.

In the tarred file I found that 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 /module/kernel/parameters/*
        module-processor-parameters.txt     - from
/module/processor/parameters/*
        sys-module-radeon-parameters.txt    - from /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

I found that 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 
    xrandr --output DisplayPort-${1} --mode 2560x1440

suggesting there might be a timing problem that needs to be addressed.


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.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.


More information about the dri-devel mailing list