Bug 76153

Created attachment 95771 [details]
snapshot

Have you tried older released kernels like v3.13 as good kernels? Or maybe even older?

Without a good kernel it's not really a regression.

Definitely looks funny though. Does this only happen with eDP or also with external screens?

(In reply to comment #2)
> Have you tried older released kernels like v3.13 as good kernels? Or maybe
> even older?
> 
> Without a good kernel it's not really a regression.
> 
> Definitely looks funny though. Does this only happen with eDP or also with
> external screens?

It's passed on testing(2014-02-06), but now it's always failed, whether I changed back to the kernel I test passed before(like -testing 6f0e07a64d32442a06a6e85f9dc461ade5b30148) or changed to older testdispaly tool.

It happens on external screen too, I plugged HDMI the run the test, it shown for small screens, two eDP screens on top and two HDMI screens on buttom.

This smells funny ...

BIOS upgrade?

Tried to always cold-boot between testing?

It could be that there's a w/a bit surviving or something nasty like this.

Or maybe there's a slight .config change or something else.

Please try to find a working kernel again and then try to isolate what exactly breaks here.

(In reply to comment #4)
> This smells funny ...
> 
> BIOS upgrade?
> 
> Tried to always cold-boot between testing?
> 
> It could be that there's a w/a bit surviving or something nasty like this.
> 
> Or maybe there's a slight .config change or something else.
> 
> Please try to find a working kernel again and then try to isolate what
> exactly breaks here.

We hadn't upgrade BIOS, and always cold-boot.

We will try to isolate it further, thanks.

We found the first bad commit on -next-queued branch. this commit unable to revert.

d7bf63f2465b3b6335dd66ffbf387768d81a59d5 is the first bad commit
commit d7bf63f2465b3b6335dd66ffbf387768d81a59d5
Author: Damien Lespiau <damien.lespiau@intel.com>
Date:   Mon Sep 30 14:21:50 2013 +0100

    drm/i915: Use adjusted_mode in the fastboot hack to disable pfit

    When booting with i915.fastboot=1, we always take tha code path and end
    up undoing what we're trying to do with adjusted_mode.

    Hopefully, as the fastboot hardware readout code is using adjusted_mode
    as well, it should be equivalent.

    Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

:040000 040000 fe0f718e4556e914236c97c1fe9179ccb3b31376 5575582971ba7f4419cc5ca7dff9b4ba2e0d8a2f M      drivers

Can you please test with i915.fastboot=0 and check whether you can still reproduce the bug?

(In reply to comment #7)
> Can you please test with i915.fastboot=0 and check whether you can still
> reproduce the bug?

With i915.fastboot=0 on latest -nightly (efa7f7f220e08cab9140f5ad678ab5e956879159), this bug unable to reproduce. thanks.

CC'ing Damien for comments on the bisect result.

(In reply to comment #7)
> Can you please test with i915.fastboot=0 and check whether you can still
> reproduce the bug?

Daniel, could you please explain a little bit about option fastboot.
By searching Kernel, I found "Try to skip unnecessary mode sets at boot time".
But what's the 'unnecessary' mode sets? Does it mean there're many times mode setting during system booting or i915 loading?

Is this still an issue with current nightly?

(In reply to comment #11)
> Is this still an issue with current nightly?

Test passed on BDW/HSW/IVB with latest -nightly commit(4a3d32734bdcef6813b31f06a58430436e98711e)

(In reply to comment #12)
> (In reply to comment #11)
> > Is this still an issue with current nightly?
> 
> Test passed on BDW/HSW/IVB with latest -nightly
> commit(4a3d32734bdcef6813b31f06a58430436e98711e)

Could you do a reverse bisect between d7bf63f246 and current -nightly to see which commit got rid of the problem? Make sure you boot with i915.fastboot=1.

(In reply to comment #13)
> (In reply to comment #12)
> (In reply to comment #11)
> > Is this still an
> issue with current nightly?
> 
> Test passed on BDW/HSW/IVB with latest
> -nightly
> commit(4a3d32734bdcef6813b31f06a58430436e98711e)

Could you do a
> reverse bisect between d7bf63f246 and current -nightly to see which commit
> got rid of the problem? Make sure you boot with i915.fastboot=1.

Is this info critical? I want to avoid spending effort on this if not critical.

Hi Gordon,

Reverting the bisected commit is the best way to make sure the bisect result makes sense. git bisect often ends up in a commit that is not the culprit and knowing if a git revert fixes the issues is a definitive way to be sure.

I'd argue that should be the last step in the bisect script, give this info. Sometimes a git revert is not possible or easy though, in which case we can't do that.

(In reply to comment #15)
> Hi Gordon,
> 
> Reverting the bisected commit is the best way to make sure the bisect result
> makes sense. git bisect often ends up in a commit that is not the culprit
> and knowing if a git revert fixes the issues is a definitive way to be sure.
> 
> I'd argue that should be the last step in the bisect script, give this info.
> Sometimes a git revert is not possible or easy though, in which case we
> can't do that.

Damien, I fully agree with you that reverting the bisected commit is the best way to ensure the bisect result (although it doesn't always apply).

But in this case, I don't think Imre is doubting the bisect result. Instead, the bug has been fixed, and he wants to know which commit fixes the bug. I'd check if this is really necessary as it won't be trivial effort (as the test is not automated so auto-bisect won't help here).

(In reply to comment #13)
> (In reply to comment #12)
> > (In reply to comment #11)
> > > Is this still an issue with current nightly?
> > 
> > Test passed on BDW/HSW/IVB with latest -nightly
> > commit(4a3d32734bdcef6813b31f06a58430436e98711e)
> 
> Could you do a reverse bisect between d7bf63f246 and current -nightly to see
> which commit got rid of the problem? Make sure you boot with i915.fastboot=1.

I think this issue not only causes by kernel. I can not reproduce this bug on the bad commit now.

(In reply to comment #16)
> (In reply to comment #15)
> > Hi Gordon,
> > 
> > Reverting the bisected commit is the best way to make sure the bisect result
> > makes sense. git bisect often ends up in a commit that is not the culprit
> > and knowing if a git revert fixes the issues is a definitive way to be sure.
> > 
> > I'd argue that should be the last step in the bisect script, give this info.
> > Sometimes a git revert is not possible or easy though, in which case we
> > can't do that.
> 
> Damien, I fully agree with you that reverting the bisected commit is the
> best way to ensure the bisect result (although it doesn't always apply).
> 
> But in this case, I don't think Imre is doubting the bisect result.
> Instead, the bug has been fixed, and he wants to know which commit fixes
> the bug. I'd check if this is really necessary as it won't be trivial
> effort (as the test is not automated so auto-bisect won't help here).

Yes, I wanted to know which commit fixed the issue. But I realize that at this point it's not worth the effort: the bug was reported too long time ago and based on comment 17, the bisect result isn't useful any more (either because the bisect result wasn't correct in the first place or something above the kernel fixed/hid the bug). Assuming this fixed now.

Verified.

Closing (>2 years) old verified+fixed