| What | Removed | Added |
|---|---|---|
| Component | Driver/Radeon | DRM/Radeon |
| Version | 7.7 (2012.06) | unspecified |
| Assignee | xorg-driver-ati@lists.x.org | dri-devel@lists.freedesktop.org |
| Product | xorg | DRI |
| QA Contact | xorg-team@lists.x.org |
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.
| What | Removed | Added |
|---|---|---|
| Severity | normal | major |
Apparently after several kernel versions later hibernate is st= ill 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 12509=
7 [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=3Dio+mem,owns=3Dio+mem,locks=3Dnone [ 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 clie= nt
(In reply to JATothrim from comment #9) > Apparently after several kernel versions later h= ibernate is still broken on > my machine. :( >=20 > 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. >=20 > Sympthoms: > -No panic is displayed. The machine freezes completly soon as radeon t= ries > to hibernate (to swap disk 8GiB). No way to soft reset. > -On resuming first display VTs are showing up weird: resolution is sam= e as > second display (1680x1050) but parts beyond that reso of the FullHD di= splay > are corrupted (pink pixel noise). > -[drm:si_dpm_set_power_state [radeon]] *ERROR* si_set_sw_state failed = gets > outputed on suspend/resume. >=20 > 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=3D0" in the = kernel, if you experience crashing or just pixelated weirdness?
| What | Removed | Added |
|---|---|---|
| Status | NEW | RESOLVED |
| Resolution | --- | MOVED |
-- 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.