Bug 51190 - [RADEON:KMS:RV370:RESUME] garbage on screen (console or X) after suspend-resume with radeon (KMS only)
Summary: [RADEON:KMS:RV370:RESUME] garbage on screen (console or X) after suspend-resu...
Status: RESOLVED MOVED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Radeon (show other bugs)
Version: unspecified
Hardware: x86 (IA32) Linux (All)
: medium major
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-06-17 23:29 UTC by cyberbat
Modified: 2019-11-19 08:27 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

Attachments
full kernel 3.5rc2 log (90.90 KB, text/plain)
2012-06-17 23:29 UTC, cyberbat 		no flags Details
.config (69.92 KB, text/plain)
2012-06-17 23:30 UTC, cyberbat 		no flags Details
console with garbage (133.29 KB, image/jpeg)
2012-06-17 23:31 UTC, cyberbat 		no flags Details
X with garbage (232.70 KB, image/jpeg)
2012-06-17 23:32 UTC, cyberbat 		no flags Details
View All

Description cyberbat 2012-06-17 23:29:42 UTC 
Created attachment 63153 [details]
full kernel 3.5rc2 log

Screen on my Samsung R50 notebook with AMD Mobility Radeon X300 (RV370 chipset)
become completely unusable after resume (watch screenshots). I've tested
different kernels from 2.6.32 till 3.5rc2. Just the same thing. The thing
happens only with KMS turned on. I have tried suspend from X (Xfce) and from
console (using pm-suspend).


I repeatedly get following errors in kernel log after resume:

Jun 15 18:56:39 localhost kernel: radeon 0000:01:00.0: GPU lockup CP stall for
more than 10000msec
Jun 15 18:56:39 localhost kernel: radeon 0000:01:00.0: GPU lockup (waiting for
0x000000000000023d last fence id 0x000000000000023c)
Jun 15 18:56:39 localhost kernel: Failed to wait GUI idle while programming
pipes. Bad things might happen.
Jun 15 18:56:39 localhost kernel: radeon 0000:01:00.0: (r300_asic_reset:392)
RBBM_STATUS=0x80010140
Jun 15 18:56:39 localhost kernel: radeon 0000:01:00.0: (r300_asic_reset:411)
RBBM_STATUS=0x80010140
Jun 15 18:56:39 localhost kernel: radeon 0000:01:00.0: (r300_asic_reset:423)
RBBM_STATUS=0x00000140
Jun 15 18:56:39 localhost kernel: radeon 0000:01:00.0: GPU reset succeed
Jun 15 18:56:39 localhost kernel: radeon 0000:01:00.0: GPU reset succeed
Jun 15 18:56:39 localhost kernel: radeon 0000:01:00.0: f5eaf400 unpin not
necessary
Jun 15 18:56:39 localhost kernel: [drm] radeon: 1 quad pipes, 1 Z pipes
initialized.
Jun 15 18:56:39 localhost kernel: [drm] PCIE GART of 512M enabled (table at
0x00000000D0040000).
Jun 15 18:56:39 localhost kernel: radeon 0000:01:00.0: WB enabled
Jun 15 18:56:39 localhost kernel: radeon 0000:01:00.0: fence driver on ring 0
use gpu addr 0x00000000b0000000 and cpu addr 0xff8de000
Jun 15 18:56:39 localhost kernel: [drm] radeon: ring at 0x00000000B0001000
Jun 15 18:56:39 localhost kernel: [drm] ring test succeeded in 1 usecs
Jun 15 18:56:39 localhost kernel: [drm] ib test succeeded in 0 usecs
...
Jun 15 18:58:32 localhost kernel: radeon 0000:01:00.0: GPU lockup CP stall for
more than 10000msec
Jun 15 18:58:32 localhost kernel: radeon 0000:01:00.0: GPU lockup (waiting for
0x0000000000000490 last fence id 0x000000000000033b)
Jun 15 18:58:32 localhost kernel: Failed to wait GUI idle while programming
pipes. Bad things might happen.
Jun 15 18:58:32 localhost kernel: radeon 0000:01:00.0: (r300_asic_reset:392)
RBBM_STATUS=0x80010140
Jun 15 18:58:32 localhost kernel: radeon 0000:01:00.0: (r300_asic_reset:411)
RBBM_STATUS=0x80010140
Jun 15 18:58:32 localhost kernel: radeon 0000:01:00.0: (r300_asic_reset:423)
RBBM_STATUS=0x00000140
Jun 15 18:58:32 localhost kernel: radeon 0000:01:00.0: GPU reset succeed
Jun 15 18:58:32 localhost kernel: radeon 0000:01:00.0: GPU reset succeed
Jun 15 18:58:32 localhost kernel: radeon 0000:01:00.0: f5eaf400 unpin not
necessary
Jun 15 18:58:32 localhost kernel: [drm] radeon: 1 quad pipes, 1 Z pipes
initialized.
Jun 15 18:58:32 localhost kernel: [drm] PCIE GART of 512M enabled (table at
0x00000000D0040000).
Jun 15 18:58:32 localhost kernel: radeon 0000:01:00.0: WB enabled
Jun 15 18:58:32 localhost kernel: radeon 0000:01:00.0: fence driver on ring 0
use gpu addr 0x00000000b0000000 and cpu addr 0xff8de000
Jun 15 18:58:32 localhost kernel: [drm] radeon: ring at 0x00000000B0001000
Jun 15 18:58:32 localhost kernel: [drm] ring test succeeded in 1 usecs
Jun 15 18:58:32 localhost kernel: [drm] ib test succeeded in 0 usecs
Jun 15 19:00:46 localhost /usr/sbin/gpm[1110]: *** info
[daemon/processrequest.c(42)]: 
Jun 15 19:00:46 localhost /usr/sbin/gpm[1110]: Request on 6 (console 1)
Jun 15 19:01:42 localhost kernel: radeon 0000:01:00.0: GPU lockup CP stall for
more than 200579msec
Jun 15 19:01:42 localhost kernel: radeon 0000:01:00.0: GPU lockup (waiting for
0x000000000000058f)
Jun 15 19:01:42 localhost kernel: radeon 0000:01:00.0: failed to get a new IB
(-35)
Jun 15 19:01:42 localhost kernel: [drm:radeon_cs_ib_chunk] *ERROR* Failed to
get ib !
Jun 15 19:01:42 localhost kernel: Failed to wait GUI idle while programming
pipes. Bad things might happen.
Jun 15 19:01:42 localhost kernel: radeon 0000:01:00.0: (r300_asic_reset:392)
RBBM_STATUS=0x80010140
Jun 15 19:01:42 localhost kernel: radeon 0000:01:00.0: (r300_asic_reset:411)
RBBM_STATUS=0x80010140
Jun 15 19:01:42 localhost kernel: radeon 0000:01:00.0: (r300_asic_reset:423)
RBBM_STATUS=0x00000140
Jun 15 19:01:42 localhost kernel: radeon 0000:01:00.0: GPU reset succeed
Jun 15 19:01:42 localhost kernel: radeon 0000:01:00.0: GPU reset succeed

I recognize that I have really old notebook, but It has enough power for my
tasks so it will be good to use KMS on it cause I loose a lot of features of X
without it.
Comment 1 cyberbat 2012-06-17 23:30:56 UTC 
Created attachment 63154 [details]
.config
Comment 2 cyberbat 2012-06-17 23:31:44 UTC 
Created attachment 63155 [details]
console with garbage
Comment 3 cyberbat 2012-06-17 23:32:37 UTC 
Created attachment 63156 [details]
X with garbage

Xorg started with Xfce and garbage on the screen. It's thunar window on the
screen under the garbage.
Comment 4 Michel Dänzer 2012-06-19 09:45:43 UTC 
(In reply to comment #4)
> I have tried suspend from X (Xfce) and from console (using pm-suspend).

Have you also tried writing mem to /sys/power/state directly?
Comment 5 cyberbat 2012-06-19 10:23:59 UTC 
(In reply to comment #4)
> (In reply to comment #4)
> > I have tried suspend from X (Xfce) and from console (using pm-suspend).
> 
> Have you also tried writing mem to /sys/power/state directly?

No. I'll try tomorrow. I don't have my notebook now.

Do I correctly understand that I should try to do
echo -n "3" > /sys/power/state
?

May be I should turn something on to produce more verbose output for debugging?
Comment 6 Michel Dänzer 2012-06-19 10:46:10 UTC 
(In reply to comment #5)
> Do I correctly understand that I should try to do
> echo -n "3" > /sys/power/state

No, I mean writing the string 'mem'. I don't know what if anything writing 3 will do.
Comment 7 cyberbat 2012-06-20 10:56:44 UTC 
(In reply to comment #6)

> No, I mean writing the string 'mem'. I don't know what if anything writing 3
> will do.

I've tried echo -n "mem" > /sys/power/state

Just the same behavior as described.
Comment 8 cyberbat 2012-06-20 11:00:28 UTC 
I got following in dmesg after restoring after mem > /sys/power/state:

radeon 0000:01:00.0: restoring config space at offset 0xf (was 0x1ff, writing 0x10a)
radeon 0000:01:00.0: restoring config space at offset 0x6 (was 0x0, writing 0xc0100000)
radeon 0000:01:00.0: restoring config space at offset 0x4 (was 0x8, writing 0xd0000008)
radeon 0000:01:00.0: restoring config space at offset 0x3 (was 0x0, writing 0x8)
radeon 0000:01:00.0: restoring config space at offset 0x1 (was 0x100107, writing 0x100507)

...

[drm] PCIE GART of 512M enabled (table at 0x00000000D0040000).
radeon 0000:01:00.0: WB enabled
[drm] radeon: ring at 0x00000000B0001000
[drm:r100_ring_test] *ERROR* radeon: ring test failed (scratch(0x15E4)=0xCAFEDEAD)
[drm:r100_cp_init] *ERROR* radeon: cp isn't working (-22).
radeon 0000:01:00.0: failed initializing CP (-22).
Comment 9 Martin Peres 2019-11-19 08:27:41 UTC 
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/amd/issues/277.

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.