diff mbox

274ad65c9d02 ("drm/radeon: hard reset r600 and newer GPU when hibernating.")

Message ID 1734348573.4433814.1465336312228.JavaMail.zimbra@redhat.com (mailing list archive)
State New, archived
Headers show

Commit Message

Jerome Glisse June 7, 2016, 9:51 p.m. UTC 
> On Mon, Jun 06, 2016 at 05:40:19PM -0400, Jerome Glisse wrote:
> > Brokens how ? Symptoms ?
> 
> Whoops, sorry, I meant to elaborate...
> 
> After doing:
> 
>         echo "shutdown" > /sys/power/disk
>         echo "disk" > /sys/power/state
> 
> screen goes blank but machine remains powered on and doesn't go off. No
> responses to keyboard presses, etc. The only thing left to do is the
> reset button.

Ok i don't have too much time to dig into r600 i assume that r700 breaks
the same way so could you verify that attached patch fix the issue for
you. Note that video decoding is likely broken for you after hibernation
but you might have never notice it.

Cheers,
Jérôme

Comments

Christian König June 8, 2016, 7:38 a.m. UTC | #1 
Am 07.06.2016 um 23:51 schrieb Jerome Glisse:
>> On Mon, Jun 06, 2016 at 05:40:19PM -0400, Jerome Glisse wrote:
>>> Brokens how ? Symptoms ?
>> Whoops, sorry, I meant to elaborate...
>>
>> After doing:
>>
>>          echo "shutdown" > /sys/power/disk
>>          echo "disk" > /sys/power/state
>>
>> screen goes blank but machine remains powered on and doesn't go off. No
>> responses to keyboard presses, etc. The only thing left to do is the
>> reset button.
> Ok i don't have too much time to dig into r600 i assume that r700 breaks
> the same way so could you verify that attached patch fix the issue for
> you. Note that video decoding is likely broken for you after hibernation
> but you might have never notice it.

Patch is Reviewed-by: Christian König <christian.koenig@amd.com>.

Please keep me CCed if you have time looking into this.

Regards,
Christian.

>
> Cheers,
> Jérôme
Borislav Petkov June 8, 2016, 11:36 a.m. UTC | #2 
On Tue, Jun 07, 2016 at 05:51:52PM -0400, Jerome Glisse wrote:
> Ok i don't have too much time to dig into r600 i assume that r700 breaks
> the same way so could you verify that attached patch fix the issue for
> you. Note that video decoding is likely broken for you after hibernation
> but you might have never notice it.

Probably. And that means I really haven't noticed.

How do I test video decoding? mplayer seems to work fine :)

> From 8ed42906e430880ce01bc6f175f1c7c180529353 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Glisse?= <jglisse@redhat.com>
> Date: Tue, 7 Jun 2016 17:43:04 -0400
> Subject: [PATCH] drm/radeon: do not hard reset GPU while freezing on r600/r700
>  family
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
> 
> Seems r600/r700 does not like hard reset while freezing for hibernation
> (regression due to 274ad65c9d02bdcbee9bae045517864c3521d530 which itself
> is a fix for hibernation on some GPU families). Until i can debug further
> issue with r600, let just disable this for r600/r700 as they are very
> similar family and bug affecting one likely affect the other.
> 
> Signed-off-by: Jérôme Glisse <jglisse@redhat.com>

Reported-and-tested-by: Borislav Petkov <bp@suse.de>
Christian König June 8, 2016, 11:50 a.m. UTC | #3 
Am 08.06.2016 um 13:36 schrieb Borislav Petkov:
> On Tue, Jun 07, 2016 at 05:51:52PM -0400, Jerome Glisse wrote:
>> Ok i don't have too much time to dig into r600 i assume that r700 breaks
>> the same way so could you verify that attached patch fix the issue for
>> you. Note that video decoding is likely broken for you after hibernation
>> but you might have never notice it.
> Probably. And that means I really haven't noticed.
>
> How do I test video decoding? mplayer seems to work fine :)

What's the output of mplayer? Mplayer usually uses video acceleration 
when it is available.

Regards,
Christian.

>
>>  From 8ed42906e430880ce01bc6f175f1c7c180529353 Mon Sep 17 00:00:00 2001
>> From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Glisse?= <jglisse@redhat.com>
>> Date: Tue, 7 Jun 2016 17:43:04 -0400
>> Subject: [PATCH] drm/radeon: do not hard reset GPU while freezing on r600/r700
>>   family
>> MIME-Version: 1.0
>> Content-Type: text/plain; charset=UTF-8
>> Content-Transfer-Encoding: 8bit
>>
>> Seems r600/r700 does not like hard reset while freezing for hibernation
>> (regression due to 274ad65c9d02bdcbee9bae045517864c3521d530 which itself
>> is a fix for hibernation on some GPU families). Until i can debug further
>> issue with r600, let just disable this for r600/r700 as they are very
>> similar family and bug affecting one likely affect the other.
>>
>> Signed-off-by: Jérôme Glisse <jglisse@redhat.com>
> Reported-and-tested-by: Borislav Petkov <bp@suse.de>
>
Borislav Petkov June 8, 2016, 1:26 p.m. UTC | #4 
On Wed, Jun 08, 2016 at 01:50:28PM +0200, Christian König wrote:
> What's the output of mplayer? Mplayer usually uses video acceleration when
> it is available.

Something like this?

libavformat version 56.23.105 (internal)
libavformat file format detected.
[lavf] stream 0: video (h264), -vid 0
[lavf] stream 1: audio (aac), -aid 0, -alang eng
VIDEO:  [H264]  1280x720  24bpp  23.976 fps  1702.9 kbps (207.9 kbyte/s)
Clip info:
 major_brand: mp42
 minor_version: 0
 compatible_brands: isommp42
 creation_time: 2015-09-24 14:54:07
Load subtitles in ./
==========================================================================
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
libavcodec version 56.26.100 (internal)
Selected video codec: [ffh264] vfm: ffmpeg (FFmpeg H.264)
==========================================================================
==========================================================================
Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders
AUDIO: 44100 Hz, 2 ch, floatle, 192.0 kbit/6.80% (ratio: 23999->352800)
Selected audio codec: [ffaac] afm: ffmpeg (FFmpeg AAC (MPEG-2/MPEG-4 Audio))
==========================================================================
AO: [alsa] 48000Hz 2ch floatle (4 bytes per sample)
Starting playback...
Movie-Aspect is 1.78:1 - prescaling to correct movie aspect.
VO: [xv] 1280x720 => 1280x720 Planar YV12 
A:   1.5 V:   1.5 A-V:  0.001 ct:  0.041   0/  0  8%  2%  1.3% 0 0
Christian König June 8, 2016, 1:30 p.m. UTC | #5 
Yes, exactly.

> VO: [xv] 1280x720 => 1280x720 Planar YV12
Mplayer is using xv without any acceleration (except for color space 
conversion).

Try forcing mplayer to use VDPAU with "mplayer -vo vdpau $file".

Regards,
Christian.

Am 08.06.2016 um 15:26 schrieb Borislav Petkov:
> On Wed, Jun 08, 2016 at 01:50:28PM +0200, Christian König wrote:
>> What's the output of mplayer? Mplayer usually uses video acceleration when
>> it is available.
> Something like this?
>
> libavformat version 56.23.105 (internal)
> libavformat file format detected.
> [lavf] stream 0: video (h264), -vid 0
> [lavf] stream 1: audio (aac), -aid 0, -alang eng
> VIDEO:  [H264]  1280x720  24bpp  23.976 fps  1702.9 kbps (207.9 kbyte/s)
> Clip info:
>   major_brand: mp42
>   minor_version: 0
>   compatible_brands: isommp42
>   creation_time: 2015-09-24 14:54:07
> Load subtitles in ./
> ==========================================================================
> Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
> libavcodec version 56.26.100 (internal)
> Selected video codec: [ffh264] vfm: ffmpeg (FFmpeg H.264)
> ==========================================================================
> ==========================================================================
> Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders
> AUDIO: 44100 Hz, 2 ch, floatle, 192.0 kbit/6.80% (ratio: 23999->352800)
> Selected audio codec: [ffaac] afm: ffmpeg (FFmpeg AAC (MPEG-2/MPEG-4 Audio))
> ==========================================================================
> AO: [alsa] 48000Hz 2ch floatle (4 bytes per sample)
> Starting playback...
> Movie-Aspect is 1.78:1 - prescaling to correct movie aspect.
> VO: [xv] 1280x720 => 1280x720 Planar YV12
> A:   1.5 V:   1.5 A-V:  0.001 ct:  0.041   0/  0  8%  2%  1.3% 0 0
>
Borislav Petkov June 8, 2016, 1:47 p.m. UTC | #6 
On Wed, Jun 08, 2016 at 03:30:34PM +0200, Christian König wrote:

> Try forcing mplayer to use VDPAU with "mplayer -vo vdpau $file".

All good. Actually, this hw accel thing is much better, I better make it
default :-P

libavformat version 56.23.105 (internal)
libavformat file format detected.
[lavf] stream 0: video (h264), -vid 0
[lavf] stream 1: audio (aac), -aid 0, -alang eng
VIDEO:  [H264]  1280x720  24bpp  23.976 fps  1702.9 kbps (207.9 kbyte/s)
Clip info:
 major_brand: mp42
 minor_version: 0
 compatible_brands: isommp42
 creation_time: 2015-09-24 14:54:07
Load subtitles in ./
==========================================================================
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
libavcodec version 56.26.100 (internal)
Selected video codec: [ffh264] vfm: ffmpeg (FFmpeg H.264)
==========================================================================
==========================================================================
Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders
AUDIO: 44100 Hz, 2 ch, floatle, 192.0 kbit/6.80% (ratio: 23999->352800)
Selected audio codec: [ffaac] afm: ffmpeg (FFmpeg AAC (MPEG-2/MPEG-4 Audio))
==========================================================================
AO: [alsa] 48000Hz 2ch floatle (4 bytes per sample)
Starting playback...
Movie-Aspect is 1.78:1 - prescaling to correct movie aspect.
VO: [vdpau] 1280x720 => 1280x720 Planar YV12 
A:   3.5 V:   3.5 A-V:  0.000 ct:  0.042   0/  0  8%  1%  1.3% 0 0
Borislav Petkov June 8, 2016, 1:55 p.m. UTC | #7 
On Wed, Jun 08, 2016 at 03:47:12PM +0200, Borislav Petkov wrote:
> All good. Actually, this hw accel thing is much better, I better make it
> default :-P

And yes, this is with Jérôme's fix to exclude r600 and r700 from hard
reset before hibernation. And after a s2d cycle I did earlier.
Jerome Glisse June 8, 2016, 2:06 p.m. UTC | #8 
> On Wed, Jun 08, 2016 at 03:47:12PM +0200, Borislav Petkov wrote:
> > All good. Actually, this hw accel thing is much better, I better make it
> > default :-P
> 
> And yes, this is with Jérôme's fix to exclude r600 and r700 from hard
> reset before hibernation. And after a s2d cycle I did earlier.
> 

To be clear, you mean that after hibernation video acceleration keeps working ? Can
you copy radeon dmesg after hibernation cycle (once you resumed from hibernation).

Cheers,
Jérôme
Borislav Petkov June 8, 2016, 2:18 p.m. UTC | #9 
On Wed, Jun 08, 2016 at 10:06:23AM -0400, Jerome Glisse wrote:
> To be clear, you mean that after hibernation video acceleration keeps working ?

Apparently. At lest the vdpau output looks fine to me.

> Can you copy radeon dmesg after hibernation cycle (once you resumed
> from hibernation).

$ dmesg | grep -Ei "(radeon|drm)"

...

  (boot messages)

...
[    8.149356] fbcon: radeondrmfb (fb0) is primary device
[    8.218800] radeon 0000:01:00.0: fb0: radeondrmfb frame buffer device
[    8.238402] [drm] Initialized radeon 2.45.0 20080528 for 0000:01:00.0 on minor 0

<-- hibernate.

[   64.711657] [drm] enabling PCIE gen 2 link speeds, disable with radeon.pcie_gen2=0
[   64.714898] [drm] PCIE GART of 512M enabled (table at 0x0000000000142000).
[   64.714920] radeon 0000:01:00.0: WB enabled
[   64.714923] radeon 0000:01:00.0: fence driver on ring 0 use gpu addr 0x0000000020000c00 and cpu addr 0xffff88042b342c00
[   64.715123] radeon 0000:01:00.0: fence driver on ring 5 use gpu addr 0x00000000000521d0 and cpu addr 0xffffc900030121d0
[   64.745988] [drm] ring test on 0 succeeded in 1 usecs
[   64.920633] [drm] ring test on 5 succeeded in 1 usecs
[   64.920637] [drm] UVD initialized successfully.
[   64.920652] [drm] ib test on ring 0 succeeded in 0 usecs
[   65.128759] ata1.00: supports DRM functions and may not be fully accessible
[   65.128799] ata2.00: supports DRM functions and may not be fully accessible
[   65.133700] ata1.00: supports DRM functions and may not be fully accessible
[   65.133811] ata2.00: supports DRM functions and may not be fully accessible
[   65.566744] [drm] ib test on ring 5 succeeded

Let me know if you need more stuff dumped.
Grigori Goronzy June 8, 2016, 3:28 p.m. UTC | #10 
On 2016-06-08 15:47, Borislav Petkov wrote:
> On Wed, Jun 08, 2016 at 03:30:34PM +0200, Christian König wrote:
> 
>> Try forcing mplayer to use VDPAU with "mplayer -vo vdpau $file".
> 
> All good. Actually, this hw accel thing is much better, I better make 
> it
> default :-P
> 

Are you sure it is using accelerated decoding? CPU load should be just 
1-2%. AFAIR you still have to explicitly enable the hardware accelerated 
codecs with mplayer. It might have changed at some point. Also try mpv 
instead, maybe. It's easier to enable decoding with that player, just 
specify --hwdec=vdpau on the command line and it'll use accelerated 
decoding whenever it can.

Grigori
Borislav Petkov June 8, 2016, 4:32 p.m. UTC | #11 
On Wed, Jun 08, 2016 at 05:28:53PM +0200, Grigori Goronzy wrote:
> Are you sure it is using accelerated decoding? CPU load should be just 1-2%.

Ha, good point. So with mplayer vo=vdpau, CPU load was at something over 12%.

Doing:

$ mpv --vo=vdpau --hwdec=vdpau $file
 (+) Video --vid=1 (*) (h264)
 (+) Audio --aid=1 --alang=eng (*) (aac)
Trying to use hardware decoding.
AO: [alsa] 48000Hz stereo 2ch float
VO: [vdpau] 1280x720 vdpau
AV: 00:00:50 / 00:02:36 (32%) A-V:  0.000

did bring it down to 5-6ish.

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
12482 boris     20   0 1026628  74272  47632 S   5.6  0.5   0:02.77 mpv

so I'm guessing this should be using hw accel now...

In any case, output looks fine again too.

Thanks.
Alex Deucher June 8, 2016, 4:44 p.m. UTC | #12 
On Wed, Jun 8, 2016 at 12:32 PM, Borislav Petkov <bp@alien8.de> wrote:
> On Wed, Jun 08, 2016 at 05:28:53PM +0200, Grigori Goronzy wrote:
>> Are you sure it is using accelerated decoding? CPU load should be just 1-2%.
>
> Ha, good point. So with mplayer vo=vdpau, CPU load was at something over 12%.
>
> Doing:
>
> $ mpv --vo=vdpau --hwdec=vdpau $file
>  (+) Video --vid=1 (*) (h264)
>  (+) Audio --aid=1 --alang=eng (*) (aac)
> Trying to use hardware decoding.
> AO: [alsa] 48000Hz stereo 2ch float
> VO: [vdpau] 1280x720 vdpau
> AV: 00:00:50 / 00:02:36 (32%) A-V:  0.000
>
> did bring it down to 5-6ish.
>
>   PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
> 12482 boris     20   0 1026628  74272  47632 S   5.6  0.5   0:02.77 mpv
>
> so I'm guessing this should be using hw accel now...
>
> In any case, output looks fine again too.

If the ring and IB tests pass on resume, you should be good to go.

Alex

>
> Thanks.
>
> --
> Regards/Gruss,
>     Boris.
>
> ECO tip #101: Trim your mails when you reply.
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
Borislav Petkov June 8, 2016, 4:51 p.m. UTC | #13 
On Wed, Jun 08, 2016 at 12:44:12PM -0400, Alex Deucher wrote:
> If the ring and IB tests pass on resume, you should be good to go.

Yap, they do. I pasted that output earlier but here it is again:

[   64.745988] [drm] ring test on 0 succeeded in 1 usecs
[   64.920633] [drm] ring test on 5 succeeded in 1 usecs
[   64.920637] [drm] UVD initialized successfully.
[   64.920652] [drm] ib test on ring 0 succeeded in 0 usecs
Alex Deucher June 9, 2016, 3:40 p.m. UTC | #14 
On Wed, Jun 8, 2016 at 12:51 PM, Borislav Petkov <bp@alien8.de> wrote:
> On Wed, Jun 08, 2016 at 12:44:12PM -0400, Alex Deucher wrote:
>> If the ring and IB tests pass on resume, you should be good to go.
>
> Yap, they do. I pasted that output earlier but here it is again:
>
> [   64.745988] [drm] ring test on 0 succeeded in 1 usecs
> [   64.920633] [drm] ring test on 5 succeeded in 1 usecs
> [   64.920637] [drm] UVD initialized successfully.
> [   64.920652] [drm] ib test on ring 0 succeeded in 0 usecs

I've applied Jerome's fix to my tree.

Thanks,

Alex

>
> --
> Regards/Gruss,
>     Boris.
>
> ECO tip #101: Trim your mails when you reply.
diff mbox

Patch

From 8ed42906e430880ce01bc6f175f1c7c180529353 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Glisse?= <jglisse@redhat.com>
Date: Tue, 7 Jun 2016 17:43:04 -0400
Subject: [PATCH] drm/radeon: do not hard reset GPU while freezing on r600/r700
 family
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Seems r600/r700 does not like hard reset while freezing for hibernation
(regression due to 274ad65c9d02bdcbee9bae045517864c3521d530 which itself
is a fix for hibernation on some GPU families). Until i can debug further
issue with r600, let just disable this for r600/r700 as they are very
similar family and bug affecting one likely affect the other.

Signed-off-by: Jérôme Glisse <jglisse@redhat.com>
---
 drivers/gpu/drm/radeon/radeon_device.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/radeon_device.c b/drivers/gpu/drm/radeon/radeon_device.c
index e721e6b..e61c763 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -1631,7 +1631,7 @@  int radeon_suspend_kms(struct drm_device *dev, bool suspend,
 	radeon_agp_suspend(rdev);
 
 	pci_save_state(dev->pdev);
-	if (freeze && rdev->family >= CHIP_R600) {
+	if (freeze && rdev->family >= CHIP_CEDAR) {
 		rdev->asic->asic_reset(rdev, true);
 		pci_restore_state(dev->pdev);
 	} else if (suspend) {
-- 
2.1.0