Bug 71908

What does the garbage look like? Please attach a photograph so that we check for a pattern.

Please also file the calltrace as a new bug.

Created attachment 89669 [details]
picture of X  after resume from S3

add the picture of X  after resume from S3

(In reply to comment #1)
> What does the garbage look like? Please attach a photograph so that we check
> for a pattern.
> 
> Please also file the calltrace as a new bug.

Here is the new bug about calltrace: https://bugs.freedesktop.org/show_bug.cgi?id=71980, thanks.

Please take a new picture which is actually sharp - besides that it shows a monitor I have no idea what's going on. Also a screenshot before the resume would be good to compare. Finally please attach the xrandr config when this happens.

Created attachment 89735 [details]
Before S3

Created attachment 89736 [details]
After resume from S3

(In reply to comment #4)
> Please take a new picture which is actually sharp - besides that it shows a
> monitor I have no idea what's going on. Also a screenshot before the resume
> would be good to compare. Finally please attach the xrandr config when this
> happens.

Please check the picture in attachment. 
Here is the Xrandr config below:
----------------------------------
Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 32767 x 32767
eDP1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 282mm x 165mm
   1920x1080      60.0*+
   1400x1050      60.0
   1280x1024      60.0
   1280x960       60.0
   1024x768       60.0
   800x600        60.3     56.2
   640x480        59.9
VGA1 disconnected (normal left inverted right x axis y axis)
HDMI1 disconnected (normal left inverted right x axis y axis)
DP1 disconnected (normal left inverted right x axis y axis)
HDMI2 disconnected (normal left inverted right x axis y axis)
VIRTUAL1 disconnected (normal left inverted right x axis y axis)

I still don't really see what's going on since due to the black background I have no idea where the screen starts/ends. Also the picture is still blurry - it looks like you need a better camera (or more light).

For screenshots to be useful I need to be able to count pixels at full magnification.

Also are you already on the latest bios version for this machine?

Created attachment 89880 [details]
no grabage fullscreen

Created attachment 89881 [details]
no grabage close-up

Created attachment 89882 [details]
Grabage fullscreen

Created attachment 89883 [details]
Grabage close-up

(In reply to comment #9)
> Also are you already on the latest bios version for this machine?
I used bios version is BBAY_x64_R_V68_30.

I had update the screenshots, thanks.

This is indeed rather funny. Just to check: Is the corruption always the colorful bar at the top and the patch more in the middle of the screen?

The top could be the rings somehow, but no idea what the middle one is ...

Top bar looks just shy of 0.5M of garbage (16*4 lines), which is a bit more than the 3 rings on byt would use. Otoh byt doesn't have the aliasing ppgtt enabled.

Please also grab the raw framebuffer with igt/tools/intel_framebuffer_dump when you see this corruptions and attach it here.

(In reply to comment #15)
> The top could be the rings somehow, but no idea what the middle one is ...

Considering it is so neatly aligned, I would say it was the cursor.

(In reply to comment #15)
> This is indeed rather funny. Just to check: Is the corruption always the
> colorful bar at the top and the patch more in the middle of the screen?
> 
> The top could be the rings somehow, but no idea what the middle one is ...

The corruption always the colorful bar at the top, but the patch in the middle of the screen shown only one time.

I cannot reproduce this bug now.

Operation steps:
----------------
1. Input xinit & in console
2. Try to do some operation on X
3. Press Ctrl+ Alt + F1 Switch to console
4. echo mem > /sys/power/state
5. Press any key to resume 
6. Press Ctrl+ Alt + F2 switch to X, the X will doesn't show garbage.

The operation step which different with before is only step 2. After do the operations above, I cannot reproduce this bug anymore.

(In reply to comment #20)
> I cannot reproduce this bug now.
> 
> Operation steps:
> ----------------
> 1. Input xinit & in console
> 2. Try to do some operation on X
> 3. Press Ctrl+ Alt + F1 Switch to console
> 4. echo mem > /sys/power/state
> 5. Press any key to resume 
> 6. Press Ctrl+ Alt + F2 switch to X, the X will doesn't show garbage.
> 
> The operation step which different with before is only step 2. After do the
> operations above, I cannot reproduce this bug anymore.

Two questions:
- Why exactly do you switch to the console to do the suspend test? This should also work from within X, and now that we have switchless suspend/resume it's important to test this.
- To clarify: You only see the garbage if you leave out 2. but as soon as you do something in X the corruption doesn't show up? Can you please tell what exactly you're doing in 2 (moving mouse, typing in xterm, starting another application, ... please be precise)?

(In reply to comment #21)
> (In reply to comment #20)
> > I cannot reproduce this bug now.
> > 
> > Operation steps:
> > ----------------
> > 1. Input xinit & in console
> > 2. Try to do some operation on X
> > 3. Press Ctrl+ Alt + F1 Switch to console
> > 4. echo mem > /sys/power/state
> > 5. Press any key to resume 
> > 6. Press Ctrl+ Alt + F2 switch to X, the X will doesn't show garbage.
> > 
> > The operation step which different with before is only step 2. After do the
> > operations above, I cannot reproduce this bug anymore.
> 
> Two questions:
> - Why exactly do you switch to the console to do the suspend test? This
> should also work from within X, and now that we have switchless
> suspend/resume it's important to test this.
Switch to console isn't necessary to run suspend/resume test, but run suspend/resume test from X, this bug unable to reproduce.
> - To clarify: You only see the garbage if you leave out 2. but as soon as
> you do something in X the corruption doesn't show up? Can you please tell
> what exactly you're doing in 2 (moving mouse, typing in xterm, starting
> another application, ... please be precise)?
In step2, I only typed command ‘ cd /GFX/Test/Intel_gpu_tools/intel-gpu-tools/tools/’ in xterm.

Ok, a few more questions:
- Does the corruption ever disappear if you do stuff in X (like move cursor, type into xterm or start firefox or a gl app or something else that consumes lots of gfx memory)?
- Does a vt-switch to console and back to X restore the display?

This is a very peculiar failure mode indeed.

Also, can you please double-check the bisect by reverting the bad commit on latest -nightly? I just want to make sure that this isn't a timing issue or something nasty like that.

(In reply to comment #23)
> Ok, a few more questions:
> - Does the corruption ever disappear if you do stuff in X (like move cursor,
> type into xterm or start firefox or a gl app or something else that consumes
> lots of gfx memory)?
> - Does a vt-switch to console and back to X restore the display?
If I do stuff in X(move cursor or type into xtern), then go to S3, the corruption will don't show; If the corruption had shown, it will doesn't disappear no matter how I do stuff in X.
> 
> This is a very peculiar failure mode indeed.
> 
> Also, can you please double-check the bisect by reverting the bad commit on
> latest -nightly? I just want to make sure that this isn't a timing issue or
> something nasty like that.
This commit is on -fixes branch, I tried to do revert on latest -fixes kernel(f1c4f43c13dc7ed381b10fa293fe63759b16a398), this bug unable to reproduce after reverting.

Does this prevent the corruption too?  Try to repro here now.

diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c b/drivers/gpu/drm/i915/i915_
index d284d89..f123f0d 100644
--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -317,6 +317,8 @@ i915_gem_object_create_stolen(struct drm_device *dev, u32 si
        struct drm_mm_node *stolen;
        int ret;
 
+       return NULL;
+
        if (!drm_mm_initialized(&dev_priv->mm.stolen))
                return NULL;

(In reply to comment #25)
> Does this prevent the corruption too?  Try to repro here now.
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c
> b/drivers/gpu/drm/i915/i915_
> index d284d89..f123f0d 100644
> --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
> +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
> @@ -317,6 +317,8 @@ i915_gem_object_create_stolen(struct drm_device *dev,
> u32 si
>         struct drm_mm_node *stolen;
>         int ret;
>  
> +       return NULL;
> +
>         if (!drm_mm_initialized(&dev_priv->mm.stolen))
>                 return NULL;

The bug unable to reproduce on -fixes commit 0d1430a3f4b7cfd8779b78740a4182321f3ca7f3 with the patch. Thanks.

I see the bug here too.  And this seems to work around the issue, but I don't know why... are the GTT maps not set up properly at this point or something?

diff --git a/drivers/gpu/drm/i915/intel_fbdev.c b/drivers/gpu/drm/i915/intel_fbd
index 284c3eb..695b574 100644
--- a/drivers/gpu/drm/i915/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/intel_fbdev.c
@@ -322,7 +322,7 @@ void intel_fbdev_set_suspend(struct drm_device *dev, int sta
         * been restored from swap. If the object is stolen however, it will be
         * full of whatever garbage was left in there.
         */
-       if (state == FBINFO_STATE_RUNNING && ifbdev->ifb.obj->stolen)
+       if (state == FBINFO_STATE_RUNNING && ifbdev->ifb.obj->stolen && 0)
                memset_io(info->screen_base, 0, info->screen_size);
 
        fb_set_suspend(info, state);

I don't see this anymore on current -nightly with the following reverts:

commit ee19117879cb11067458f6380683d2fb53055466
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date:   Wed Dec 11 15:53:59 2013 -0800

    Revert "cpufreq: suspend governors on system suspend/hibernate"
    
    This reverts commit 5a87182aa21d6d5d306840feab9321818dd3e2a3.

commit 753d2a517fdb57e6820fda6e9a1ca0aeae43dcd5
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date:   Mon Dec 9 15:52:23 2013 -0800

    Revert "intel_pstate: Add Baytrail support"
    
    This reverts commit 19e77c28dbf1972305da0dfeb92a62f83df3a91d.

can you confirm?

(In reply to comment #28)
> I don't see this anymore on current -nightly with the following reverts:
> 
> commit ee19117879cb11067458f6380683d2fb53055466
> Author: Jesse Barnes <jbarnes@virtuousgeek.org>
> Date:   Wed Dec 11 15:53:59 2013 -0800
> 
>     Revert "cpufreq: suspend governors on system suspend/hibernate"
>     
>     This reverts commit 5a87182aa21d6d5d306840feab9321818dd3e2a3.
> 
> commit 753d2a517fdb57e6820fda6e9a1ca0aeae43dcd5
> Author: Jesse Barnes <jbarnes@virtuousgeek.org>
> Date:   Mon Dec 9 15:52:23 2013 -0800
> 
>     Revert "intel_pstate: Add Baytrail support"
>     
>     This reverts commit 19e77c28dbf1972305da0dfeb92a62f83df3a91d.
> 
> can you confirm?

This bug still reproducible on latest -nightly (f0404eaa3ab8607058a3581e0d691d35ca4b79bd).

And these two commits above unable to find with commends in -nightly git log, we found a similar commit, the details is:
commit 77bd2adb97271c5f2237cfacf5984cc810033131
Merge: 754ac45 d4faadd
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Mon Dec 9 09:29:42 2013 -0800

    Merge tag 'pm-3.13-rc3-fixup' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/l

    Pull power management fixup from Rafael Wysocki:
     "This reverts two cpufreq commits that fixed issues for some people,
      but broke things for others, so revert them and we'll need to fix the
      original problems differently"

    * tag 'pm-3.13-rc3-fixup' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux
      Revert "cpufreq: fix garbage kobjects on errors during suspend/resume"
      Revert "cpufreq: suspend governors on system suspend/hibernate"

*** Bug 72334 has been marked as a duplicate of this bug. ***

Hm, stolen corruption? Please test this patch:

http://patchwork.freedesktop.org/patch/17588/

(In reply to comment #31)
> Hm, stolen corruption? Please test this patch:
> 
> http://patchwork.freedesktop.org/patch/17588/

The bug unable to reproduce with this patch. thanks.

commit ec14ba47791965d2c08e0a681ff44eacbf3c4553
Author: Akash Goel <akash.goel@intel.com>
Date:   Mon Jan 13 16:24:45 2014 +0530

    drm/i915: Fix the offset issue for the stolen GEM objects

Checked on latest -fixes(ec14ba47791965d2c08e0a681ff44eacbf3c4553), this bug had fixed. Thanks.

Closing old verified.