Bug 27062

Created attachment 44152 [details]
screenshot before suspend

Created attachment 44162 [details]
screenshot after supending the devices

Created attachment 44172 [details]
screenshot during resume with screen corruption (partial scrolling) in the upper right part

Created attachment 44182 [details]
screenshot after resume and VT switchback (about to start the next iteration)

Is there a modesetting capable kernel which does not exhibit these problems? 
(>v2.6.29 are candidates, but I guess for testing I would actually go backwards from 2.6.36)

Created attachment 50262 [details]
console corruption during resume

Under 2.6.38-rc7+, I can't observe the scrolling corruption anymore, but this other type of corruption is still very prominent. It's also not new, appeared together with the scrolling corruption before, but the other was easier to capture, probably because I'm testing with a monolithic kernel now, and the ATA driver halts the resume process for a second before flipping back to the original framebuffer contents. This picture is fully reproducible by stopping in the initramfs phase, then

(initramfs) cd /sys/power
(initramfs) echo core >pm_test
(initramfs) echo mem >state

However, further echo mem >state operations don't show the issue, only the first.

Created attachment 50272 [details]
scrolling the picture left with the keyboard in the Geeqie image viewer

Possibly related: submitting attachment 50262 [details] I noticed display artifacts (white vertical lines) during scrolling the zoomed fullscreen image in the Geeqie image viewer program (an X application). This screenshot was taken while actually scrolling the image, thus the apparent tiling.

Created attachment 50282 [details]
the final (stationary) result after scrolling the picture to extreme left

This is the end result, after the view hit the left border of the image. The increasing spacing of the vertical lines corresponds to the acceleration of the scrolling.
I reckon this may as well be an application bug, just showing here in case it's related.

(In reply to comment #5)
> Is there a modesetting capable kernel which does not exhibit these problems? 
> (>v2.6.29 are candidates, but I guess for testing I would actually go
> backwards
> from 2.6.36)

I went the other way, and found that 2.6.30 and 2.6.29 definitely exhibit this problem. (Since suspend was broken on my machine before b690e96c, I could test these only by inserting a break statement after /* Next, disable display pipes */ in intel_display.c.)  I didn't test 2.6.31-36, but wouldn't expect better.

I also tested 79e53945 (DRM: i915: add mode setting support), which didn't even switch into a high-res framebuffer mode, but still exhibited the problem. Then I thought maybe it's not related to i915 at all and disabled CONFIG_DRM_I915, but then I didn't even got my original console back after resume -- but I didn't see screen corruption either. (Blindly issuing the reset command rebooted the machine all right.)

Plese retest with 3.3, 2.6.37 is rather ancient in graphics-land.

Yes, under 3.3 I can still see console corruption in the timestamp area during resume before the original screen contents are restored, and scrolling in Geeqie still leaves white lines behind.

Ooh 855, I bet Chris wants this one. :)

Oh crikey. Can you turn on all the memory debugging options under kernel hacking and try testing with nomodeset? The former because there is nothing special about the fb at that time, it is just a coherent mapping onto the scanout so I presume something is going badly in memory. The latter will help confirm if it i915.ko that is at fault.

The good news: 3.3.1 fixed the console corruption issues during STR resume!

And the bad: the permanent corruption after scrolling the fullscreen image in Geeqie stayed with me even under 3.3.3. Interestingly, scrolling down and left works fine, while scrolling up and right introduces occasional white lines. Also, scrolling left via the keyboard is unbearably slow.

(Am I supposed to change the bug status now?)

I think the scrolling bug will be fixed (by removing the ability to scroll!) with

commit 62fb376e214d3c1bfdf6fbb77dac162f6da04d7e
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Mon Mar 26 21:15:53 2012 +0100

    drm: Validate requested virtual size against allocated fb size
    
    mplayer -vo fbdev tries to create a screen that is twice as tall as the
    allocated framebuffer for "doublebuffering". By default, and all in-tree
    users, only sufficient memory is allocated and mapped to satisfy the
    smallest framebuffer and the virtual size is no larger than the actual.
    For these users, we should therefore reject any userspace request to
    create a screen that requires a buffer larger than the framebuffer
    originally allocated.
    
    References: https://bugs.freedesktop.org/show_bug.cgi?id=38138
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Cc: stable@kernel.org
    Signed-off-by: Dave Airlie <airlied@redhat.com>

which hit upstream in v3.4-rc2 and 3.3.2 and 3.3.3. Instead that explains the speed, Geeqie is doing a full transfer for every scroll, and also suggests where the root cause is. We don't intend to accelerate fbdev as it is a must not fail output for panics. Is there a reason why you need to do it this way?

I'm afraid I created some confusion here. This report was mostly about the framebuffer console corruption during STR resume, which is present in 3.3 but fixed in 3.3.1. Meanwhile I added some info about screen corruption under Geeqie, but I run Geeqie under X.Org 1.7.7 with intel driver module version 2.13.0, not on the framebuffer. So this part may well be a totally unrelated userspace bug, but I can't judge this.

Let me add one more detail. I'm running with two monitors now, xrandr reports:

Screen 0: minimum 320 x 200, current 1920 x 1848, maximum 2048 x 2048
LVDS1 connected 1024x768+0+1080 (normal left inverted right x axis y axis) 0mm x 0mm
   1024x768       60.0*+   85.0     75.0     70.1     60.0*    43.5  
[...]
VGA1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 477mm x 268mm
   1920x1080      60.0*+
[...]

And if I switch Geeqie into fullscreen mode on LVDS1, the top row of pixels leaks into the bottom row of VGA1. This happens similarly in other screen configurations, too. Also Mplayer leaks a single row of overlay-blue into the other screen if I switch info fullscreen. So Geeqie isn't alone at least. May this be an X driver bug?

The top line wrapping around onto the bottom of the display is still likely to be an issue in the kernel modesetting. On the other hand, the Geeqie corruption definitely sounds like a xf86-video-intel driver bug; 2.13.0 is quite old and a number of corruption bugs have been fixed since then.

(And if you have an example of a slow X application, I also want to hear about it :)

Ferenc, if you are happy we have the fb corruption resolved, can you open a new bug for the bad modesetting (and if you want to try fresh xf86-video-intel drivers, a bug for Xorg Driver/Intel on bugs.freedesktop.org), and lets close this particular bug.

Sure, the console is all right now, closing this bug.

I'll look into the remaining issues; trying a newer Xorg driver isn't entirely off the plate, so let's start with that.
Thanks all for your assistance!