Bug 67713

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.

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?

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?

Created attachment 83585 [details]
Dmesg from a suspend resume

No bios freeze but some errors - posting incase they're relevant

OK I've gotten a dmesg for when it freezes up

I can't change VTs but I was able to SSH in

Created attachment 83685 [details]
Dmesg showing issue

Changing the bug name - perhaps the atombios issue was a red herring

Created attachment 115642 [details]
dmesg still with errors

Dmesg Erik

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

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

No longer have access to hardware

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).

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