From mboxrd@z Thu Jan 1 00:00:00 1970 From: bugzilla-daemon@freedesktop.org Subject: [Bug 107784] [AMD tahiti XT] displayport broken Date: Thu, 06 Sep 2018 16:20:19 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0197571344==" Return-path: Received: from culpepper.freedesktop.org (culpepper.freedesktop.org [131.252.210.165]) by gabe.freedesktop.org (Postfix) with ESMTP id 6731E6E6F2 for ; Thu, 6 Sep 2018 16:20:19 +0000 (UTC) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org --===============0197571344== Content-Type: multipart/alternative; boundary="15362508190.e4743.31624" Content-Transfer-Encoding: 7bit --15362508190.e4743.31624 Date: Thu, 6 Sep 2018 16:20:19 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://bugs.freedesktop.org/ Auto-Submitted: auto-generated https://bugs.freedesktop.org/show_bug.cgi?id=3D107784 --- Comment #17 from Sylvain BERTRAND --- On Thu, Sep 06, 2018 at 02:22:18PM +0000, bugzilla-daemon@freedesktop.org wrote: > https://bugs.freedesktop.org/show_bug.cgi?id=3D107784 >=20 > --- Comment #16 from Michel D=C3=A4nzer --- > "this commit" being 019cddc88f9e4ae0de2c76802f7137210c2101aa (the I2C mer= ge), > 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. >=20 > This most likely means that you're not yet able to reliably determine tha= t 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 yo= ur 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 mo= st 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 res= pect 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 , w= hich I cannot match, I'm all eyes and hears. --=20 You are receiving this mail because: You are the assignee for the bug.= --15362508190.e4743.31624 Date: Thu, 6 Sep 2018 16:20:19 +0000 MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://bugs.freedesktop.org/ Auto-Submitted: auto-generated

Comme= nt # 17 on bug 10778= 4 from Sylvain BERTRAND 
On Thu, Sep 06, 2018 at 02:22:18PM +0000, bugzilla-daemon@freedesktop.org
wrote:
> https://bugs.freedesktop.org/show_bug.=
cgi?id=3D107784
>=20
> --- Comment #16 from Mich=
el D=C3=A4nzer <michel@dae=
nzer.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 the=
ir
> history. So you previously considered commit
> e2a9ca29b5edc89da2fddeae30e1070b272395c5 as both bad and good. That's =
the
> inconsistency.
>=20
> 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 whic=
h happens at
boot,
once xorg tries to program my displayport screen. That would be based on yo=
ur
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 mo=
st
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 sta=
te (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 , w=
hich
I cannot match, I'm all eyes and hears.

You are receiving this mail because:
  • You are the assignee for the bug.
= --15362508190.e4743.31624-- --===============0197571344== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== --===============0197571344==--