Bug 67713

Summary: Freezes on Trinity 7500G
Product: DRI Reporter: Mike Lothian <mike>
Component: DRM/RadeonAssignee: Default DRI bug account <dri-devel>
Status: RESOLVED INVALID QA Contact:
Severity: normal    
Priority: medium CC: mike
Version: XOrg git   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
Dmesg
none
Dmesg from a suspend resume
none
Dmesg showing issue
none
dmesg still with errors none

Description Mike Lothian 2013-08-03 14:01:14 UTC
Created attachment 83583 [details]
Dmesg

A trinity system freezes if X is in the forefront 

Caught this when I was in a VT - I'll attach the dmesg

RADEON_VA=0 is coded in /etc/environment as a solution to frequent freeze ups (I'm not sure if this is still required or not) bug 65958 

00:01.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Trinity [Radeon HD 7500G] [1002:990a]

Let me know if there's anything else you need
Comment 1 Alex Deucher 2013-08-03 14:11:44 UTC
Does it also happen with DPM disabled?  Is there any trigger for the freezes?

I think the atombios messages are just a symptom of the GPU being hung rather than directly related to the root of the bug.
Comment 2 Alex Deucher 2013-08-03 14:14:14 UTC
If it's not DPM related, is this a regression?  Did you also update mesa?  It could also be a mesa bug that triggers a GPU hang.  If it is a regression and you can narrow down the component, can you bisect?
Comment 3 Mike Lothian 2013-08-03 15:11:47 UTC
I don't know what triggers it - it's my dad's laptop and it's fairly new - the freezing started happening again when I activated DPM as they cleared up after the RADEON_VA=0 fix

The system is currently running the latest mesa

This is been happening for the last 2 weeks (since I activated DPM) and it's still happening (possibly less frequently) since all the stack was updated again

In the above dmesg I was in a VT with just a gnome desktop running in the background - could it be when the screen powers off from lack of input and switching it back on that causes the issue - is there a way to trigger that behaviour manually to test it?

I'd rather not have to switch DPM permanently 

Also will I need to run with RADEON_VA=0 permanently too or is there a fix planned for that?
Comment 4 Mike Lothian 2013-08-03 15:18:53 UTC
Created attachment 83585 [details]
Dmesg from a suspend resume

No bios freeze but some errors - posting incase they're relevant
Comment 5 Mike Lothian 2013-08-06 00:21:30 UTC
OK I've gotten a dmesg for when it freezes up

I can't change VTs but I was able to SSH in
Comment 6 Mike Lothian 2013-08-06 00:22:09 UTC
Created attachment 83685 [details]
Dmesg showing issue
Comment 7 Mike Lothian 2013-08-06 00:42:20 UTC
Changing the bug name - perhaps the atombios issue was a red herring
Comment 8 Erik 2015-05-08 16:56:42 UTC
Created attachment 115642 [details]
dmesg still with errors

Dmesg Erik
Comment 9 Erik 2015-05-08 16:58:23 UTC
I had the same issue while connecting a second monitor, with the following card:

VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Trinity [Radeon HD 7660G] (prog-if 00 [VGA controller])

The problem arised when I updated to kernel 4.0.1-1-ARCH #1 SMP PREEMPT (updated some other packets also, like mesa 10.5.4-1).

It worked after the RADEON_VA=0 fix described at the beggining, but in dmesg still appears attachment 115642 [details]:

[   57.343370] [drm:atom_op_jump [radeon]] *ERROR* atombios stuck in loop for more than 5secs aborting
[   57.343388] [drm:atom_execute_table_locked [radeon]] *ERROR* atombios stuck executing 3336 (len 2642, WS 0, PS 8) @ 0x393E
[   62.462796] [drm:atom_op_jump [radeon]] *ERROR* atombios stuck in loop for more than 5secs aborting
[   62.462815] [drm:atom_execute_table_locked [radeon]] *ERROR* atombios stuck executing 3336 (len 2642, WS 0, PS 8) @ 0x393E
[   62.547688] [drm:radeon_dp_link_train [radeon]] *ERROR* clock recovery reached max voltage
[   62.547715] [drm:radeon_dp_link_train [radeon]] *ERROR* clock recovery failed
Comment 10 Mike Lothian 2015-09-11 13:51:04 UTC
I no longer have access to the hardware for this bug

If Erik doesn't want to proceed I'm happy for it to be closed
Comment 11 Mike Lothian 2016-04-15 17:56:57 UTC
No longer have access to hardware
Comment 12 Erik 2016-10-12 16:11:38 UTC
Hi guys, seems that the problem arises again. Now I've updated the kernel 4.4.23-1-lts #1, mesa 12.0.3-2.

Same error appears, while I try to extend my desktop to both monitors.

[  193.473517] [drm:atom_op_jump [radeon]] *ERROR* atombios stuck in loop for more than 5secs aborting
[  193.473551] [drm:atom_execute_table_locked [radeon]] *ERROR* atombios stuck executing 3336 (len 2642, WS 0, PS 8) @ 0x393E

Still with RADEON_VA=0 option (also tried without it).
Comment 13 Mike Lothian 2016-11-03 13:21:09 UTC
Hi Erik

You're probably best creating your own new bug and supply all the info required for the dev's to investigate. I no longer have access to this hardware anymore and your issues might be from a different bug

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.