Bug 90595

Created attachment 115972 [details]
lspci -vvv output

Created attachment 115973 [details]
dmesg

Created attachment 115974 [details]
xorg log

Oh, I should add that I'm running enlightenment as that could be at fault

$ pacman -Q|ag 'efl|enlightenment'
efl 1.14.0-1
enlightenment 0.19.5-1

I am also a victim of this bug.
It freezes/soft bricks my machine every time while resuming from hibernate - suspend to ram tough works kind of ok (tty dual monitor border corruption).
I'm running 4.2.0 vanilla kernel.

(In reply to JATothrim from comment #5)
> I am also a victim of this bug.
> It freezes/soft bricks my machine every time while resuming from hibernate -
> suspend to ram tough works kind of ok (tty dual monitor border corruption).
> I'm running 4.2.0 vanilla kernel.

Try upgrading xf86-video-ati from git. You only need to cp the src/.libs/radeon_drv.so file to /usr/lib/xorg/modules/drivers/radeon_drv.so (or your distros equivalent). Beware that X will auto-restart afterwards. I found that doing so has squashed Bug91994. However I still see [drm:si_dpm_set_power_state [radeon]] *ERROR* si_set_sw_state failed in dmesg.

(In reply to Adam Flott from comment #6)
> (In reply to JATothrim from comment #5)
> > I am also a victim of this bug.
> > It freezes/soft bricks my machine every time while resuming from hibernate -
> > suspend to ram tough works kind of ok (tty dual monitor border corruption).
> > I'm running 4.2.0 vanilla kernel.
> 
> Try upgrading xf86-video-ati from git. You only need to cp the
> src/.libs/radeon_drv.so file to /usr/lib/xorg/modules/drivers/radeon_drv.so
> (or your distros equivalent). Beware that X will auto-restart afterwards. I
> found that doing so has squashed Bug91994. However I still see
> [drm:si_dpm_set_power_state [radeon]] *ERROR* si_set_sw_state failed in
> dmesg.

I'm already using newest git mesa (Oibaf graphics drivers ppa). I also have tied self compiling the git mesa driver but no change to hibernate. However I disabled the radeon DPM power management with radeon.dpm=0 in kernel command-line and it fixed the hibernate! I still see awful lot of this '[drm:si_dpm_set_power_state [radeon]] *ERROR* si_set_sw_state failed' error in dmesg tough. Also bad is that I miss the automatic DPM..

(In reply to JATothrim from comment #7)
> 
> I'm already using newest git mesa (Oibaf graphics drivers ppa). I also have
> tied self compiling the git mesa driver but no change to hibernate. However
> I disabled the radeon DPM power management with radeon.dpm=0 in kernel
> command-line and it fixed the hibernate! I still see awful lot of this
> '[drm:si_dpm_set_power_state [radeon]] *ERROR* si_set_sw_state failed' error
> in dmesg tough. Also bad is that I miss the automatic DPM..

If you set radeon.dpm=0, you shouldn't see any of the dpm error messages in your log.  Make sure the parameter setting actually got picked up.

Apparently after several kernel versions later hibernate is still broken on my machine. :(

uname -a: Linux HyperArchMachine 4.6.3-1-ARCH #1 SMP PREEMPT Fri Jun 24 21:19:13 CEST 2016 x86_64 GNU/Linux
Operating system is Arch/Antergos.

Sympthoms:
-No panic is displayed. The machine freezes completly soon as radeon tries to hibernate (to swap disk 8GiB). No way to soft reset.
-On resuming first display VTs are showing up weird: resolution is same as second display (1680x1050) but parts beyond that reso of the FullHD display are corrupted (pink pixel noise).
-[drm:si_dpm_set_power_state [radeon]] *ERROR* si_set_sw_state failed gets outputed on suspend/resume.

Disabling DPM on boot allows machine to hibernate/resume correctly but dual display VT weirdness persists.

Created attachment 125097 [details]
lspci -vvv kernel 4.6.x

Added lspci -vvv ouput.

I too have been experiencing this issue for quite some time.  I'm running:

# uname -a
Linux hostname 4.9.0-5-amd64 #1 SMP Debian 4.9.65-3+deb9u2 (2018-01-04) x86_64 GNU/Linux

# lsb_release -a
No LSB modules are available.
Distributor ID:	Debian
Description:	Debian GNU/Linux 9.3 (stretch)
Release:	9.3
Codename:	stretch

And here's what show's up in `dmesg` every time I boot up:

# dmesg | grep -i radeon
[    2.877374] [drm] radeon kernel modesetting enabled.
[    2.896977] radeon 0000:01:00.0: VRAM: 2048M 0x0000000000000000 - 0x000000007FFFFFFF (2048M used)
[    2.896978] radeon 0000:01:00.0: GTT: 2048M 0x0000000080000000 - 0x00000000FFFFFFFF
[    2.897154] [drm] radeon: 2048M of VRAM memory ready
[    2.897155] [drm] radeon: 2048M of GTT memory ready.
[    2.902498] radeon 0000:01:00.0: firmware: direct-loading firmware radeon/pitcairn_pfp.bin
[    2.909274] radeon 0000:01:00.0: firmware: direct-loading firmware radeon/pitcairn_me.bin
[    2.909826] radeon 0000:01:00.0: firmware: direct-loading firmware radeon/pitcairn_ce.bin
[    2.911587] radeon 0000:01:00.0: firmware: direct-loading firmware radeon/pitcairn_rlc.bin
[    2.912724] radeon 0000:01:00.0: firmware: direct-loading firmware radeon/pitcairn_mc.bin
[    2.913984] radeon 0000:01:00.0: firmware: direct-loading firmware radeon/pitcairn_smc.bin
[    2.922964] [drm] radeon: dpm initialized
[    2.928860] radeon 0000:01:00.0: firmware: direct-loading firmware radeon/TAHITI_uvd.bin
[    2.930542] radeon 0000:01:00.0: firmware: direct-loading firmware radeon/TAHITI_vce.bin
[    2.949302] radeon 0000:01:00.0: WB enabled
[    2.949304] radeon 0000:01:00.0: fence driver on ring 0 use gpu addr 0x0000000080000c00 and cpu addr 0xffff998d238abc00
[    2.949305] radeon 0000:01:00.0: fence driver on ring 1 use gpu addr 0x0000000080000c04 and cpu addr 0xffff998d238abc04
[    2.949306] radeon 0000:01:00.0: fence driver on ring 2 use gpu addr 0x0000000080000c08 and cpu addr 0xffff998d238abc08
[    2.949307] radeon 0000:01:00.0: fence driver on ring 3 use gpu addr 0x0000000080000c0c and cpu addr 0xffff998d238abc0c
[    2.949308] radeon 0000:01:00.0: fence driver on ring 4 use gpu addr 0x0000000080000c10 and cpu addr 0xffff998d238abc10
[    2.949808] radeon 0000:01:00.0: fence driver on ring 5 use gpu addr 0x0000000000075a18 and cpu addr 0xffffb0f8c2c35a18
[    2.969924] radeon 0000:01:00.0: fence driver on ring 6 use gpu addr 0x0000000080000c18 and cpu addr 0xffff998d238abc18
[    2.969926] radeon 0000:01:00.0: fence driver on ring 7 use gpu addr 0x0000000080000c1c and cpu addr 0xffff998d238abc1c
[    2.969943] radeon 0000:01:00.0: radeon: MSI limited to 32-bit
[    2.970010] radeon 0000:01:00.0: radeon: using MSI.
[    2.970036] [drm] radeon: irq initialized.
[    5.136861] [drm] Radeon Display Connectors
[    5.304534] fbcon: radeondrmfb (fb0) is primary device
[    5.484728] [drm:si_dpm_set_power_state [radeon]] *ERROR* si_restrict_performance_levels_before_switch failed
[    5.576343] radeon 0000:01:00.0: fb0: radeondrmfb frame buffer device
[    5.603284] [drm] Initialized radeon 2.49.0 20080528 for 0000:01:00.0 on minor 0

Not sure if you need this, but just in case:

# dmesg | grep -i vga
[    0.000000] Console: colour VGA+ 80x25
[    0.373862] vgaarb: setting as boot device: PCI:0000:01:00.0
[    0.373863] vgaarb: device added: PCI:0000:01:00.0,decodes=io+mem,owns=io+mem,locks=none
[    0.373864] vgaarb: loaded
[    0.373864] vgaarb: bridge control possible 0000:01:00.0
[    2.805123] snd_hda_intel 0000:01:00.1: Handle vga_switcheroo audio client

(In reply to JATothrim from comment #9)
> Apparently after several kernel versions later hibernate is still broken on
> my machine. :(
> 
> uname -a: Linux HyperArchMachine 4.6.3-1-ARCH #1 SMP PREEMPT Fri Jun 24
> 21:19:13 CEST 2016 x86_64 GNU/Linux
> Operating system is Arch/Antergos.
> 
> Sympthoms:
> -No panic is displayed. The machine freezes completly soon as radeon tries
> to hibernate (to swap disk 8GiB). No way to soft reset.
> -On resuming first display VTs are showing up weird: resolution is same as
> second display (1680x1050) but parts beyond that reso of the FullHD display
> are corrupted (pink pixel noise).
> -[drm:si_dpm_set_power_state [radeon]] *ERROR* si_set_sw_state failed gets
> outputed on suspend/resume.
> 
> Disabling DPM on boot allows machine to hibernate/resume correctly but dual
> display VT weirdness persists.

I'm getting the same "tiles" on my display a moment before the x-windows system hangs.  I'm able to ssh into my box and shut it down, but box must be restarted.  Just curious, if after implementing "dpm=0" in the kernel, if you experience crashing or just pixelated weirdness?

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/amd/issues/616.