Bug 72905 - [3.12.5] dpm causes gpu reset on rv670
Summary: [3.12.5] dpm causes gpu reset on rv670
Status: RESOLVED DUPLICATE of bug 66963
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Radeon (show other bugs)
Version: XOrg git
Hardware: x86-64 (AMD64) Linux (All)
: medium major
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-12-20 09:08 UTC by Thierry Vignaud
Modified: 2013-12-20 15:53 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

Attachments
dmesg with dpm enabled (48.91 KB, text/plain)
2013-12-20 09:08 UTC, Thierry Vignaud 		no flags Details
dmesg without dpm enabled (81.70 KB, text/plain)
2013-12-20 09:09 UTC, Thierry Vignaud 		no flags Details
Xorg.0.log (without dpm) (67.82 KB, text/plain)
2013-12-20 09:09 UTC, Thierry Vignaud 		no flags Details
Xorg.0.log (with dpm) (48.11 KB, text/plain)
2013-12-20 09:10 UTC, Thierry Vignaud 		no flags Details
cat /sys/kernel/debug/dri/64/radeon_pm_info without dpm (164 bytes, text/plain)
2013-12-20 09:10 UTC, Thierry Vignaud 		no flags Details
cat /sys/kernel/debug/dri/64/radeon_pm_info with dpm (75 bytes, text/plain)
2013-12-20 09:10 UTC, Thierry Vignaud 		no flags Details
View All

Description Thierry Vignaud 2013-12-20 09:08:00 UTC 
I tried booting with radeon.dpm=1 with Mageia 4 beta 2 (kernel-3.12.5 & mesa-10.0).
Gfx cards is RV670 ([Radeon HD 3690/3850], PCI ids: vendor=1002 device=9505 subv=174b subd=2542)

First xorg often results in black screen then gnome failure.
Subsequent xorgs are slow to death

dmesg is filled with:
+*ERROR* atombios stuck in loop for more than 5secs aborting
+*ERROR* atombios stuck executing CE58 (len 349, WS 0, PS 4) @ 0xCE75

or:
+*ERROR* atombios stuck in loop for more than 5secs aborting
+*ERROR* atombios stuck executing CDBE (len 153, WS 0, PS 4) @ 0xCDD4
+*ERROR* atombios stuck executing B9E2 (len 760, WS 0, PS 0) @ 0xBB6B
+*ERROR* atombios stuck executing B920 (len 138, WS 0, PS 8) @ 0xB92A
Comment 1 Thierry Vignaud 2013-12-20 09:08:30 UTC 
Created attachment 91024 [details]
dmesg with dpm enabled
Comment 2 Thierry Vignaud 2013-12-20 09:09:14 UTC 
Created attachment 91025 [details]
dmesg without dpm enabled

Note I mistakely run twice "perl -pi -e 's!^\[[^\]]*\] !!' dmesg?" in order to get rid of timestamps so the "[drm]" string is lost in both dmesgs
Comment 3 Thierry Vignaud 2013-12-20 09:09:51 UTC 
Created attachment 91026 [details]
Xorg.0.log (without dpm)
Comment 4 Thierry Vignaud 2013-12-20 09:10:07 UTC 
Created attachment 91027 [details]
Xorg.0.log (with dpm)
Comment 5 Thierry Vignaud 2013-12-20 09:10:38 UTC 
Created attachment 91028 [details]
cat /sys/kernel/debug/dri/64/radeon_pm_info without dpm
Comment 6 Thierry Vignaud 2013-12-20 09:10:49 UTC 
Created attachment 91029 [details]
cat /sys/kernel/debug/dri/64/radeon_pm_info with dpm
Comment 7 Thierry Vignaud 2013-12-20 09:13:51 UTC 
Actually, it's mesa-10.0.1
Note that in both cases, dmesgs show "HDMI: invalid ELD data byte 0" whereas I'm using a regular VGA cable. Also r600 seems to regularly freeze Xorg for a couple seconds (up to ~1mn) from time to times.
Comment 8 Thierry Vignaud 2013-12-20 10:05:55 UTC 
Hold on.
I'd an issue where my E2180 microcode wasn't updated on boot.
It looks like those issues go away once the microcode update has been fixed.
Strange...
Comment 9 Alex Deucher 2013-12-20 13:46:30 UTC 
The atombios errors are just a side effect of a gpu hang caused by dpm.  dpm isn't stable yet on rv670 asics which is why it's disabled by default.
Comment 10 Alex Deucher 2013-12-20 13:49:49 UTC 

*** This bug has been marked as a duplicate of bug 66963 ***
Comment 11 Thierry Vignaud 2013-12-20 15:23:16 UTC 
OK for the dpm case, but when the option wasn't there, I still saw Xorg freezing from times to times
Comment 12 Alex Deucher 2013-12-20 15:53:13 UTC 
(In reply to comment #11)
> OK for the dpm case, but when the option wasn't there, I still saw Xorg
> freezing from times to times

That's a separate issue and should be filed separately.

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.