Bug 196563 - Garbled graphics after resume on an R100-based card
Summary: Garbled graphics after resume on an R100-based card
Status: NEW
Alias: None
Product: Drivers
Classification: Unclassified
Component: Video(DRI - non Intel) (show other bugs)
Hardware: i386 Linux
: P1 normal
Assignee: drivers_video-dri
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-08-02 07:34 UTC by felix
Modified: 2017-10-16 18:47 UTC (History)
1 user (show)

See Also:
Kernel Version: 4.11.0-2-686-pae (Debian sid)
Subsystem:
Regression: No
Bisected commit-id:


Attachments
lspci -v fragment (652 bytes, text/plain)
2017-08-02 07:37 UTC, felix
Details
Output of 'radeontool regmatch *' before suspending (20.32 KB, text/plain)
2017-08-02 07:38 UTC, felix
Details
Output of 'radeontool regmatch *' right after resuming (20.31 KB, text/plain)
2017-08-02 07:39 UTC, felix
Details
Output of 'radeontool regmatch *' after resuming and restoring VBE state (20.32 KB, text/plain)
2017-08-02 07:41 UTC, felix
Details

Description felix 2017-08-02 07:34:09 UTC
When I suspend and then resume my laptop with R100-based graphics, the display becomes garbled. A single scanline from the video memory is stretched over the entire height of the screen; this is usually the scanline containing the caret. Under X11, one can observe the mouse pointer sprite being corrupted as well. When switching VTs, flashes of the correct, 'intended' screen contents can be sometimes seen, but the screen instantly reverts to this single stretched scanline just described.

The issue can be readily worked around via the usual 'vbetool vbestate' hack; although even then the display contents can appear incorrect after resume, as if other programs' framebuffers were pasted onto the screen. Moreover, if the restore part doesn't run soon enough after resuming, the restored screen becomes glitched with randomly lit pixels. The glitching is more severe the more time passes between resuming and restoring VBE state; it is as if the video RAM wasn't being refreshed correctly until the VBE state is restored. Thus, best results are achieved by storing the VBE state on a tmpfs. But in any case, it's nothing a temporary VT switch can't fix.
Comment 1 felix 2017-08-02 07:37:43 UTC
Created attachment 257789 [details]
lspci -v fragment
Comment 2 felix 2017-08-02 07:38:48 UTC
Created attachment 257791 [details]
Output of 'radeontool regmatch *' before suspending
Comment 3 felix 2017-08-02 07:39:50 UTC
Created attachment 257793 [details]
Output of 'radeontool regmatch *' right after resuming
Comment 4 felix 2017-08-02 07:41:20 UTC
Created attachment 257795 [details]
Output of 'radeontool regmatch *' after resuming and restoring VBE state

Note You need to log in before you can comment on or make changes to this bug.