Bug 25017

Summary:	computer fails to suspend with kms enabled.
Product:	xorg	Reporter:	Matthew Monaco <matt>
Component:	Driver/Radeon	Assignee:	xf86-video-ati maintainers <xorg-driver-ati>
Status:	RESOLVED INVALID	QA Contact:	Xorg Project Team <xorg-team>
Severity:	normal
Priority:	medium	CC:	depassp, nix
Version:	7.5 (2009.10)
Hardware:	x86 (IA32)
OS:	Linux (All)
Whiteboard:
i915 platform:		i915 features:

Description Matthew Monaco 2009-11-10 07:11:44 UTC

The computer is a Dell XPS210. Here are the lspci entries for the card, the first one is the one that is active:

01:00.0 VGA compatible controller: ATI Technologies Inc RV516 [Radeon X1300/X1550 Series]
01:00.1 Display controller: ATI Technologies Inc RV516 [Radeon X1300 Pro] (Secondary)


This is only with KMS enabled. When I suspend (using pm-utils) I hear that something happens in the computer, like the hard disks turn office, but the screen does not turn off (backlight stays lit) and the computer doesn't actually suspend (fans stay on, power light does not start to slowly pulse). At this point the computer is unresponsive, I can not SSH in, my only course is to force it off.

Comment 1 Nix 2009-11-10 16:20:30 UTC

It's certainly not completely broken: for me, with an HD4870, KMS suspension (with TuxOnIce) mostly works better than non-KMS --- non-KMS locked up on resume unless I switched to text mode before suspending.

But there is *one* possible problem: I haven't yet isolated it to KMS definitively, I'm just suspicious, so this is just a heads-up.

TuxOnIce starts out with a limited set of reserved pages which are not atomically copied, for drivers to use during suspension, but (unlike with the in-tree swsusp, IIRC) this is not a hard limit. Radeon KMS touches a *lot* of pages during suspension if 3D has ever been used: I've seen figures upwards of 38000 (!!) at times, even if 3D's not in use at suspension time. If we run out, TOI recovers, expands the reserved set, and tries to copy again; as this involves allocation of (possibly much) more storage, we thaw processes and refreeze them after the allocation. This means that a freeze is not always followed by hibernation, but may be followed by a thaw and another freeze.

Radeon KMS seems to dislike this: for me, at least, this freeze/thaw/freeze cycle results in a lockup if KMS is running.

(As I said earlier, I haven't yet isolated it to KMS in particular. Without KMS running, no drivers on my system need any reserved pages at all, so the freeze/thaw/freeze cycle is never initiated, and I always get away with a single freeze round; equally, if I arrange to allocate enough reserved pages with KMS running, it suspends and resumes perfectly. So this may be a false alarm: some other driver may be at fault.)

Comment 2 Adam Jackson 2018-06-12 19:10:01 UTC

Mass closure: This bug has been untouched for more than six years, and is not
obviously still valid. Please reopen this bug or file a new report if you continue to experience issues with current releases.

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.