Bug 29062 - hp dv5000: xpress 200m 5955 + KMS does not resume from suspend
Summary: hp dv5000: xpress 200m 5955 + KMS does not resume from suspend
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Radeon (show other bugs)
Version: XOrg git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact:
Depends on:
Reported: 2010-07-14 12:00 UTC by Andres Cimmarusti
Modified: 2010-08-01 18:00 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:

dmesg (42.86 KB, text/plain)
2010-07-14 12:00 UTC, Andres Cimmarusti
no flags Details
Xorg0.log (29.23 KB, application/octet-stream)
2010-07-14 12:01 UTC, Andres Cimmarusti
no flags Details
lspci -v (7.64 KB, text/plain)
2010-07-14 12:03 UTC, Andres Cimmarusti
no flags Details
fix resume (1.20 KB, patch)
2010-07-21 20:55 UTC, Alex Deucher
no flags Details | Splinter Review

Description Andres Cimmarusti 2010-07-14 12:00:47 UTC
Created attachment 37046 [details]

When I try suspending using KMS my computer (an HP Pavilion dv5035nr laptop)
does not resume. Furthermore I've tried logging into it remotely to obtain a
backtrace from X with no success (following this procedure:
http://ubuntuforums.org/showthread.php?t=1228332). I'm letting NetworkManager
handle my network interfaces, however, I also tried using dhcp directly in the
/etc/network/interfaces file. The laptop screen is completely blank
so I can't switch to another session. The keyboard doesn't respond so it seems like the kernel crashed.

When using UMS the resume process happens perfectly.

I dedicated a large portion of the day to finding a clue to this one.
Following this advice:
I was able to extract a trace from the failed resume process:

Magic number: 0:981:799
hash matches drivers/base/power/main.c:523
pci 0000:01:05.0: hash matches
ec PNP0C09:00: hash matches

The first hash match is none other than my ATI Radeon card as I easily
verified with lspci:

01:05.0 VGA compatible controller: ATI Technologies Inc Radeon XPRESS 200M
5955 (PCIE)

However, the above link says that the likely culprit in the failed resume
process is the last hash match. This corresponds to the EC driver:

My card was, till recently, listed under embedded graphics at the AMD/ATI
website. So there appears to be some conflict when using KMS between radeon
and ec that causes the kernel to hang (that explains why I can't ssh into my
computer to get a trace).

I would appreciate some advice and guidance in further debugging this issue, since I'm flying half-blind. I have compiled my kernel with support for ACPI_DEBUG and I included a quirk David Airlie used to get suspend to work with a HP nx6125 laptop but applied for my model (http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commit;h=580b4fffbbdc3c899ee1f8189ba321bd60b48840)
Comment 1 Andres Cimmarusti 2010-07-14 12:01:55 UTC
Created attachment 37047 [details]
Comment 2 Andres Cimmarusti 2010-07-14 12:03:36 UTC
Created attachment 37048 [details]
lspci -v
Comment 3 Dave Airlie 2010-07-14 14:13:34 UTC

in Linus tree is a quirk for my rs48x laptop, you try expanding it to cover your laptop, or just force it on for testing.

drm/radeon: add quirk to make HP nx6125 laptop resume
Comment 4 Andres Cimmarusti 2010-07-15 20:57:16 UTC
Fantastic!, it works!

I forced it by just writing (like your quirk):

    /* quirk for rs4xx HP laptops to make them resume
    * - they hang on resume inside the dynclk 1 table.

Just before the /* DYN CLK 1 */ line in the radeon_combios.c file.

So, can you modify your patch to encompass my chipset? actually I know of several xpress 200 different chipsets that have this issue, see for example:


I will contact this bug reporters and will try to get them to modify their kernel source.

Thanks a lot!

Comment 5 Alex Deucher 2010-07-21 20:55:44 UTC
Created attachment 37291 [details] [review]
fix resume

I've sent the attached patch to Dave to be included upstream.

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.