dri-devel.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: bugzilla-daemon@bugzilla.kernel.org
To: dri-devel@lists.freedesktop.org
Subject: [Bug 100871] radeon fails to initialize one DisplayPort monitor
Date: Tue, 06 Sep 2016 10:28:10 +0000	[thread overview]
Message-ID: <bug-100871-2300-LzYtqFt7jN@https.bugzilla.kernel.org/> (raw)
In-Reply-To: <bug-100871-2300@https.bugzilla.kernel.org/>

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

Reg <reg@regproctor.com> changed:

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

--- Comment #14 from Reg <reg@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.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  parent reply	other threads:[~2016-09-06 10:28 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-03 16:00 [Bug 100871] New: radeon fails to initialize one DisplayPort monitor bugzilla-daemon
2015-07-03 16:00 ` [Bug 100871] " bugzilla-daemon
2015-07-03 19:29 ` bugzilla-daemon
2015-07-04 21:19 ` bugzilla-daemon
2015-07-18  3:10 ` bugzilla-daemon
2015-10-20 22:48 ` bugzilla-daemon
2015-10-20 22:56 ` bugzilla-daemon
2015-10-20 22:57 ` bugzilla-daemon
2015-10-20 22:57 ` bugzilla-daemon
2015-10-20 22:58 ` bugzilla-daemon
2015-10-20 22:58 ` bugzilla-daemon
2016-08-08 15:23 ` bugzilla-daemon
2016-09-01  8:13 ` bugzilla-daemon
2016-09-01  8:19 ` bugzilla-daemon
2016-09-01  8:20 ` bugzilla-daemon
2016-09-06 10:28 ` bugzilla-daemon [this message]
2016-09-06 10:50 ` bugzilla-daemon
2016-09-06 18:13 ` bugzilla-daemon
2022-08-08 21:37 ` bugzilla-daemon
2022-08-08 21:48 ` bugzilla-daemon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-100871-2300-LzYtqFt7jN@https.bugzilla.kernel.org/ \
    --to=bugzilla-daemon@bugzilla.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).