Bug 71067 - [drm:r600] UVD not responding OR failed testing IB on GFX ring
Summary: [drm:r600] UVD not responding OR failed testing IB on GFX ring
Status: RESOLVED MOVED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Radeon (show other bugs)
Version: XOrg git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-10-30 22:54 UTC by Timothée Ravier
Modified: 2019-11-19 08:39 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
dmesg log (82.03 KB, text/plain)
2013-10-30 22:55 UTC, Timothée Ravier
no flags Details
dmesg log freeze-cursor (101.16 KB, text/plain)
2013-10-30 22:55 UTC, Timothée Ravier
no flags Details
dmesg log freeze-boot-then-yellow (82.03 KB, text/plain)
2013-10-30 22:56 UTC, Timothée Ravier
no flags Details
dmesg log - boot then freeze at random (102.54 KB, text/plain)
2013-11-03 21:58 UTC, Timothée Ravier
no flags Details

Description Timothée Ravier 2013-10-30 22:54:13 UTC
When I boot 3.10 or 3.11 kernels, I get either one of those errors, apparently at random :
  * UVD not responding, trying to reset the VCPU
    -> Full log attached: *freeze-boot-then-yellow.log
    The display turns yellow when the X server starts. I can still use VT and there is no corruption there. I made sure that I got the latest firmware and I also checked my initrd (following instructions in 65270);

  * GPU lockup CP stall for more than 10000msec
    GPU lockup (waiting for 0x000000000000020e last fence id 0x00000000000001ec)
    r600_ib_test] *ERROR* radeon: fence wait failed (-35)
    radeon_ib_ring_tests] *ERROR* radeon: failed testing IB on GFX ring (-35)
    -> Full log attached: *freeze-cursor.log
    I can log into my graphical session, but quickly after that, everything freeze and I can only move the cursor which displays as a "corrupted" square.
    Again VT are fine.

I filed only one bug report as I get both issue using the same software and boot command line.

At the beginning I had bug 67994, which turned into this one. I tried downgrading the kernel without much success for now.

Booting with nomodeset works perfectly (with no accel/KMS obviously) and booting under Windows 7 too.
Comment 1 Timothée Ravier 2013-10-30 22:55:12 UTC
Created attachment 88381 [details]
dmesg log
Comment 2 Timothée Ravier 2013-10-30 22:55:45 UTC
Created attachment 88382 [details]
dmesg log freeze-cursor
Comment 3 Timothée Ravier 2013-10-30 22:56:25 UTC
Created attachment 88383 [details]
dmesg log freeze-boot-then-yellow
Comment 4 Alex Deucher 2013-10-31 13:02:50 UTC
Did you also update mesa?
Comment 5 Timothée Ravier 2013-10-31 13:24:16 UTC
Yes, I have mesa updated to 9.2.2. When I reported the previous bug I was using a custom kernel and testing packages provided by Arch Linux. But now I'm using only official and updated Arch Linux packages.

My laptop is four years old, so I'll try to run GPU-demanding applications on Windows to make sure it's not a hardware problem.
Comment 6 Timothée Ravier 2013-11-03 21:58:52 UTC
Created attachment 88581 [details]
dmesg log - boot then freeze at random

I managed to boot another time with modesetting enabled, but it quickly froze.

So far, every single new attempts to boot in Windows 7 have failed with a BSOD .

What's your take on this? Could it be hardware failure?
Comment 7 Alex Deucher 2013-11-04 15:07:50 UTC
(In reply to comment #6)
> Created attachment 88581 [details]
> dmesg log - boot then freeze at random
> 
> I managed to boot another time with modesetting enabled, but it quickly
> froze.
> 
> So far, every single new attempts to boot in Windows 7 have failed with a
> BSOD .
> 
> What's your take on this? Could it be hardware failure?

Could be.  Does powering down completely between booting different OSes help?
Comment 8 Christian König 2013-11-04 15:15:36 UTC
>nov. 02 09:16:44 leviathan kernel: Memory corruption detected in low memory

And directly after that the GPU gets into a reset loop. That indeed sounds like the system is somewhat broken.

Please also try 3.12, but I would rather advise to replace the hardware.
Comment 9 Timothée Ravier 2013-11-14 10:53:56 UTC
Completely powering down and removing the battery between boots does not help. I also tried 3.12 without success.

What's bothering me is that booting and not using X works. Is there any way I could disable UVD support and just keep the nice KMS'ed VTs?
Comment 10 Alex Deucher 2013-11-14 14:09:28 UTC
(In reply to comment #9)
> Completely powering down and removing the battery between boots does not
> help. I also tried 3.12 without success.
> 
> What's bothering me is that booting and not using X works. Is there any way
> I could disable UVD support and just keep the nice KMS'ed VTs?

Remove the UVD firmware from your system and initrd or patch the driver to not enable UVD:

diff --git a/drivers/gpu/drm/radeon/radeon_uvd.c b/drivers/gpu/drm/radeon/radeon_uvd.c
index 373d088..7177dbc 100644
--- a/drivers/gpu/drm/radeon/radeon_uvd.c
+++ b/drivers/gpu/drm/radeon/radeon_uvd.c
@@ -60,6 +60,8 @@ int radeon_uvd_init(struct radeon_device *rdev)
        const char *fw_name;
        int i, r;
 
+       return -EINVAL;
+
        INIT_DELAYED_WORK(&rdev->uvd.idle_work, radeon_uvd_idle_work_handler);
 
        switch (rdev->family) {
Comment 11 Martin Peres 2019-11-19 08:39:35 UTC
-- 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/400.


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.