[Bug 107784] [AMD tahiti XT] displayport broken

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Thu Sep 6 16:20:19 UTC 2018


https://bugs.freedesktop.org/show_bug.cgi?id=107784

--- Comment #17 from Sylvain BERTRAND <sylvain.bertrand at gmail.com> ---
On Thu, Sep 06, 2018 at 02:22:18PM +0000, bugzilla-daemon at freedesktop.org
wrote:
> https://bugs.freedesktop.org/show_bug.cgi?id=107784
> 
> --- Comment #16 from Michel Dänzer <michel at 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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20180906/fb6b29c2/attachment-0001.html>


More information about the dri-devel mailing list