Bug 18872 - [RADEON:KMS:R100:SUSPEND] suspend to ram problems
Summary: [RADEON:KMS:R100:SUSPEND] suspend to ram problems
Status: RESOLVED OBSOLETE
Alias: None
Product: Drivers
Classification: Unclassified
Component: Video(DRI - non Intel) (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: drivers_video-dri
URL:
Keywords:
Depends on:
Blocks: 7216
  Show dependency tree
 
Reported: 2010-09-20 18:46 UTC by Maciej Rutecki
Modified: 2013-12-10 22:09 UTC (History)
8 users (show)

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


Attachments

Description Maciej Rutecki 2010-09-20 18:46:05 UTC
Subject    : Radeon KMS r100 and STR problems
Submitter  : Richard Mittendorfer <delist@gmx.net>
Date       : 2010-09-17 18:26
Message-ID : 20100917202647.aa4b6300.delist@gmx.net
References : http://marc.info/?l=linux-kernel&m=128474802809779&w=2

This entry is being used for tracking a regression from 2.6.35. Please don't
close it until the problem is fixed in the mainline.
Comment 1 Alex Deucher 2010-09-24 14:22:26 UTC
Any chance you can track down a working kernel and bisect it?
Comment 2 Richard Mittendorfer 2010-09-24 14:37:13 UTC
Sry, no. Since I switched to KMS I was unable to get the box out of STR alive.
Comment 3 Rafael J. Wysocki 2010-09-26 20:02:10 UTC
So that's not a regression, rather the driver not working correctly on your hardware.
Comment 4 Richard Mittendorfer 2010-09-26 22:38:45 UTC
True. Not a regression. I'm using KMS since .33(?), but hesitated to report as KMS is quite new - hoping it would fix itself.. :)
Comment 5 Rafael J. Wysocki 2011-01-16 22:39:28 UTC
Is the problem still present in 2.6.37?
Comment 6 Richard Mittendorfer 2011-01-16 22:59:27 UTC
Yep, still present. On -rc8 at least, switching to final .37 next days. Ideas highly welcome.
Comment 7 Rafael J. Wysocki 2011-01-16 23:06:06 UTC
Thanks for the information.

Does it work without X (ie. if you boot into the text console)?
Comment 8 Richard Mittendorfer 2011-01-17 00:06:05 UTC
Thanks for looking into this. It's the same behavior w/ and w/o Xorg. At the STR
process the backlight goes off shortly but remains lit during suspend. The screen
goes black and stays black when out of suspend. Some flickering on/off when
entering and leaving STR. There's short harddrive activity when coming out of
suspend. Also, suspend- and power-led blink/lit as they are supposed to. The box
is then locked up, not reacting to keyboard input or even sysrq. Hard power off
required.
I've seen it coming back out of suspend halfway sane (post on lkml) but that
hardly ever happens. The only known workaround for me is to go with nomodeset
(and loose 3d acceleration as well).
Comment 9 Rafael J. Wysocki 2011-01-17 00:22:37 UTC
Does the following:

# echo core > /sys/power/pm_test
# echo mem > /sys/power/state

return to the command prompt (after about 5-10 sec) or does it hang too?
Comment 10 Richard Mittendorfer 2011-01-17 01:32:03 UTC
On .37 now with PM_DEBUG and stuff there. Above method too hangs at quite the same position (when coming out of suspend after few seconds). Nothing in syslog, dmesg pm tracing (dmesg -s 1000000 | grep 'hash matches') as well, but didn't do much testing (won't be able to test/reply for the next hrs.)
Comment 11 Maté 2011-05-23 21:10:09 UTC
Same problem with vanilla 2.6.39 on debian testing.

"At the STR process the backlight goes off shortly but remains lit during suspend. The screen goes black and stays black when out of suspend. Some flickering on/off when entering and leaving STR. There's short harddrive activity when coming out of suspend [1]. Also, suspend- and power-led blink/lit as they are supposed to. The box is then locked up, not reacting to keyboard input or even sysrq. Hard power off required."

[1] not sure about this one

There's a switch in /etc/default/acpi-support:
#RADEON_LIGHT=true

Commented or uncommented doesn't change the behavior during STR.

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