Bug 38472 - Garbage shown in console using radeon/kms on dualscreen setup after suspend/resume
Summary: Garbage shown in console using radeon/kms on dualscreen setup after suspend/r...
Status: NEW
Alias: None
Product: Drivers
Classification: Unclassified
Component: Video(DRI - non Intel) (show other bugs)
Hardware: x86-64 Linux
: P1 normal
Assignee: drivers_video-dri
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-06-28 18:17 UTC by boris64
Modified: 2016-03-23 18:36 UTC (History)
4 users (show)

See Also:
Kernel Version: 3.5.2
Subsystem:
Regression: No
Bisected commit-id:

Attachments
picture of console with garbage (116.64 KB, image/jpeg)
2011-06-28 18:17 UTC, boris64 		Details
dmesg (78.35 KB, text/plain)
2011-06-28 18:18 UTC, boris64 		Details
.config (63.54 KB, application/octet-stream)
2011-06-28 18:20 UTC, boris64 		Details
Add an attachment (proposed patch, testcase, etc.)

Description boris64 2011-06-28 18:17:39 UTC 
Created attachment 63772 [details]
picture of console with garbage

I'm seeing garbage on my framebuffer console with radeon/kms using 2 screens
(running at different resolution - screen1: 1920x1200 - screen2: 1280x1024).

This really looks... uh, let's say ugly. IMO the unused parts of the console
should be black, for example. Please check out the attached image showing
the issue. Thanks in advance!
Comment 1 boris64 2011-06-28 18:18:26 UTC 
Created attachment 63782 [details]
dmesg
Comment 2 boris64 2011-06-28 18:20:58 UTC 
Created attachment 63792 [details]
.config
Comment 3 boris64 2011-06-29 10:32:04 UTC 
Uh, i forgot the most important information:
Corruption occurs _after_ suspend/resume.
Comment 4 Andrew Morton 2011-06-29 20:34:55 UTC 
Is it a regression?  Was 2.6.39 OK?
Comment 5 boris64 2011-06-29 23:57:22 UTC 
No regression, looks like it's been there from the start.
So, same issue on 2.6.39.
Comment 6 Alex Deucher 2012-08-24 15:32:26 UTC 
Is this still an issue with a newer kernel?
Comment 7 boris64 2012-08-24 16:29:21 UTC 
Yes, it's still there on kernel-3.5.2
Comment 8 Alex Deucher 2012-08-24 16:42:47 UTC 
I think this is an issue with the drm fb helper.  Since fb doesn't handle multiple heads we only expose the smallest to the fb layer so the "extra" space on the larger heads never gets re-initialized on resume.
Note You need to log in before you can comment on or make changes to this bug.