Bug 71871 - [ALL] visual corruption when kms kicks in
Summary: [ALL] visual corruption when kms kicks in
Status: CLOSED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: XOrg git
Hardware: Other All
: medium normal
Assignee: Mika Kuoppala
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-11-21 11:15 UTC by Timo Aaltonen
Modified: 2017-07-24 22:56 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Timo Aaltonen 2013-11-21 11:15:31 UTC
There are stripes of garbage during bootup when kms kicks in, see the attached video.

booted with 3.12 on HSW-ULT machine, but it affects others too, at least IVB.
Comment 1 Timo Aaltonen 2013-11-21 11:22:13 UTC
ok so it was too big for bugzilla, put it here instead:

http://koti.kapsi.fi/~tjaalton/tmp/13110010.mp4
Comment 2 Paulo Zanoni 2013-11-21 13:45:58 UTC
Hi

You are talking about those red stripes, right? Does this happen to you only on a specific output type (e.g., HDMI, DVI, DP, eDP or VGA) or all of them? Which one was being used when you recorded the video?

I used to see this problem on my Haswell machine too, but we recently applied some missing workarounds and I can't see it anymore. Can you please test the latest drm-intel-nightly branch?

Thanks,
Paulo
Comment 3 Chris Wilson 2013-11-21 13:56:55 UTC
The cause is that we scribble over the GTT whilst the outputs are still reading from it (during BIOS -> KMS takeover). It is not yet fixed, and the regression is on all machines dating from about 3.2 - in some cases this is known to also cause a GPU hang.
Comment 4 Timo Aaltonen 2013-11-21 16:49:27 UTC
This was on a laptop, so eDP. But I have desktop SDP's too which have the same.

I'm happy to test whatever in order to get it finally fixed :)
Comment 5 Ben Widawsky 2013-11-22 01:53:13 UTC
(In reply to comment #3)
> The cause is that we scribble over the GTT whilst the outputs are still
> reading from it (during BIOS -> KMS takeover). It is not yet fixed, and the
> regression is on all machines dating from about 3.2 - in some cases this is
> known to also cause a GPU hang.

Oddly it seems to come and go for me... but definitely it has existed for a long time.
Comment 6 Ben Widawsky 2013-11-22 01:57:22 UTC
(In reply to comment #5)
> (In reply to comment #3)
> > The cause is that we scribble over the GTT whilst the outputs are still
> > reading from it (during BIOS -> KMS takeover). It is not yet fixed, and the
> > regression is on all machines dating from about 3.2 - in some cases this is
> > known to also cause a GPU hang.
> 
> Oddly it seems to come and go for me... but definitely it has existed for a
> long time.

Also, why is it always at the top 1/3 to 1/4 of the screen. Is that the difference between 80x25 vs the native mode?
Comment 7 Yu Ning 2013-11-25 06:29:27 UTC
(In reply to comment #2)
> Hi
> 
> You are talking about those red stripes, right? Does this happen to you only
> on a specific output type (e.g., HDMI, DVI, DP, eDP or VGA) or all of them?
> Which one was being used when you recorded the video?
> 
> I used to see this problem on my Haswell machine too, but we recently
> applied some missing workarounds and I can't see it anymore. Can you please
> test the latest drm-intel-nightly branch?
> 
> Thanks,
> Paulo

Hi

Thanks for the suggestions. I tested drm-intel-nightly debs [1] on a Haswell platform, the red stripes does disappeared, but instead a white strip is displayed for less than 0.1 second.

[1]: http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-nightly/current/

Thanks,
Ning
Comment 8 Yu Ning 2013-11-25 06:43:25 UTC
I made a video shot for comment #7:
http://ubuntuone.com/4jkOVo1NcF5hShk3qBuSom
Comment 9 Chris Wilson 2014-03-20 14:20:45 UTC
This should be fixed by

commit d978ef14456a38034f6c0e94a794129501f89200
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date:   Fri Mar 7 08:57:51 2014 -0800

    drm/i915: Wrap the preallocated BIOS framebuffer and preserve for KMS fbcon v12


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.