All of lore.kernel.org
 help / color / mirror / Atom feed
From: sylvain.bertrand@gmail.com
To: bugzilla-daemon@freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [Bug 107784] [AMD tahiti XT] displayport broken
Date: Thu, 6 Sep 2018 16:20:12 +0000	[thread overview]
Message-ID: <20180906162012.GA316@freedom> (raw)
In-Reply-To: <bug-107784-502-9XDv8XEi5r@http.bugs.freedesktop.org/>

On Thu, Sep 06, 2018 at 02:22:18PM +0000, bugzilla-daemon@freedesktop.org wrote:
> https://bugs.freedesktop.org/show_bug.cgi?id=107784
> 
> --- Comment #16 from Michel Dänzer <michel@daenzer.net> ---
> "this commit" being 019cddc88f9e4ae0de2c76802f7137210c2101aa (the I2C merge),
> which has two parents. Both of those parent commits contain commit
> e2a9ca29b5edc89da2fddeae30e1070b272395c5 (a TSC commit) as part of their
> history. So you previously considered commit
> e2a9ca29b5edc89da2fddeae30e1070b272395c5 as both bad and good. That's the
> inconsistency.
> 
> This most likely means that you're not yet able to reliably determine that a
> given commit is bad, e.g. due to not testing (long) enough.

Wow! Then it is even worse of what I thought. Due to the violent leap from 4.18
to 4.19, there are zillions of commits, and even nlog(n) bisect will give me
ten_s_ of commits to test.

Please, could you refine your "long enough" for a blocker pb which happens at boot,
once xorg tries to program my displayport screen. That would be based on your
experience, something to give me the order of the "long enough".

That said, I have a hinch. I am going to setup a much cleaner test env: it's a
custom distro which boots in _really_ a few seconds (not in the range of most
mainstream distros boot time)-->I am going to slow it down, on purpose
(certainly in more than 1 spot). Then, I have an efi framebuffer and I saw some
issues about this->I am going to get rid of it. Then, I am not confident in my
monitor (see my other bugs), I may use the previous artificial slow down, to
power cycle the monitor, before xorg tries to detect and program it. Well, I'll
try to figure a way to put my monitor in a "probably" cleaner state (in respect
of displayport hotplug support). Oh, and just in case of, I'll stick to the
performance cpu governor.

If you have any advice about this based on your experience at knowledge , which
I cannot match, I'm all eyes and hears.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2018-09-06 16:20 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-02 17:22 [Bug 107784] [AMD tahiti XT] displayport broken bugzilla-daemon
2018-09-02 17:28 ` bugzilla-daemon
2018-09-03  9:17 ` bugzilla-daemon
2018-09-03 10:30 ` bugzilla-daemon
2018-09-03 14:55 ` bugzilla-daemon
2018-09-05  7:19 ` bugzilla-daemon
2018-09-05 11:50 ` bugzilla-daemon
2018-09-05 12:28 ` bugzilla-daemon
2018-09-05 12:33 ` bugzilla-daemon
2018-09-05 13:38   ` sylvain.bertrand
2018-09-05 13:38 ` bugzilla-daemon
2018-09-05 17:44 ` bugzilla-daemon
2018-09-05 21:48   ` sylvain.bertrand
2018-09-05 21:48 ` bugzilla-daemon
2018-09-05 21:52 ` bugzilla-daemon
2018-09-05 21:54 ` bugzilla-daemon
2018-09-06 10:04 ` bugzilla-daemon
2018-09-06 12:31   ` sylvain.bertrand
2018-09-06 12:31 ` bugzilla-daemon
2018-09-06 14:22 ` bugzilla-daemon
2018-09-06 16:20   ` sylvain.bertrand [this message]
2018-09-06 16:20 ` bugzilla-daemon
2018-09-06 21:10   ` sylvain.bertrand
2018-09-07 21:48     ` sylvain.bertrand
2018-09-06 21:10 ` bugzilla-daemon
2018-09-07 21:48 ` bugzilla-daemon
2018-09-09  3:45   ` sylvain.bertrand
2018-09-09  3:46 ` bugzilla-daemon
2018-09-09  5:57 ` bugzilla-daemon
2018-09-09 13:05 ` bugzilla-daemon
2018-09-09 13:11 ` bugzilla-daemon
2018-09-09 14:59   ` sylvain.bertrand
2018-09-09 14:59 ` bugzilla-daemon
2018-09-10  5:20 ` bugzilla-daemon
2018-09-10  9:15 ` 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=20180906162012.GA316@freedom \
    --to=sylvain.bertrand@gmail.com \
    --cc=bugzilla-daemon@freedesktop.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.