linux-kernel - Resume problem with radeon+KMS (2.6.34-rc2 and before)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 21 Mar 2010 22:28:13 +0100
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	dri-devel@...ts.sourceforge.net
Cc:	Dave Airlie <airlied@...il.com>,
	LKML <linux-kernel@...r.kernel.org>,
	pm list <linux-pm@...ts.linux-foundation.org>,
	Jérôme Glisse <glisse@...edesktop.org>
Subject: Resume problem with radeon+KMS (2.6.34-rc2 and before)

Hi,

Some time ago I reported a problem with resuming from suspend to RAM on
HP nx6325 with radeon+KMS.

The problem was that the first resume always failed if the suspend was started
from under X.  Moreover, the resume went correctly until the last switch from
the framebuffer console (which was now controlled by the radeon driver as
well) to X that made the box hang hard.

However, if the first resume was started from the (radeon-controlled)
framebuffer console, the subsequent resume succeeded and all of the next
attempts to suspend/resume succeeded, _regardless_ of the way the suspend was
started.

At that time Dave thought it might be a problem with the nx6325's graphics
adapter that apparently was a crappy one, but today I found that _exactly_ the
same behavior was observable on Acer Ferrari One, which was quite different,
hardware-wise, from the old HP box.  For this reason I think the problem is
related to the driver itself rather than to the hardware or firmware.

The problem is reproducible on both machines with the latest git kernel
and the user space radeon_drv.so from openSUSE 11.2 (it says
module version = 6.12.4 in the X log).  The kernel and user space are 64-bit
on both machines.  [For completness, the Acer box suspends and resumes
correctly with radeon.modeset=0 and "s2ram -f -p -m".]

Should I try a newer user space X driver?  Or may the problem be related to
the 64-bitness somehow?

Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/