All of lore.kernel.org
 help / color / mirror / Atom feed
From: bugzilla-daemon@freedesktop.org
To: dri-devel@lists.freedesktop.org
Subject: [Bug 100465] Hard lockup with radeonsi driver on FirePro W600, W9000 and W9100
Date: Thu, 06 Apr 2017 16:27:39 +0000	[thread overview]
Message-ID: <bug-100465-502-OKVaiog0pr@http.bugs.freedesktop.org/> (raw)
In-Reply-To: <bug-100465-502@http.bugs.freedesktop.org/>


[-- Attachment #1.1: Type: text/plain, Size: 2087 bytes --]

https://bugs.freedesktop.org/show_bug.cgi?id=100465

--- Comment #9 from Julien Isorce <julien.isorce@gmail.com> ---
When using R600_DEBUG=check_vm on both Xorg and the gl app I can get some
output in kern.log. It looks like a "ring 0 stalled" is detected and then
follow a gpu softreset which succeeds ("GPU reset succeeded, trying to resume")
but fails to resume because:

[drm:atom_execute_table_locked [radeon]] [kworker/0:1H, 434] *ERROR* atombios
stuck executing C483 (len 254, WS 0, PS 4) @ 0xC4AD
[drm:atom_execute_table_locked [radeon]] [kworker/0:1H, 434] *ERROR* atombios
stuck executing BC59 (len 74, WS 0, PS 8) @ 0xBC8E

Then there is two: radeon_mc_wait_for_idle failure "Wait for MC idle timedout"
from si_mc_program

Finally si_startup fails because si_cp_resume fails because r600_ring_test
fails with: "radeon: ring 0 test failed (scratch(0x850C)=0xCAFEDEAD)"

But it seems it keeps looping trying to do a gpu softreset and at some point it
freezes. I need to confirm this ending scenario though but these atombios
failures are worring in the first place.

At the same time I get some "radeon_ttm_bo_destroy" notified by
"WARN_ON(!list_empty(&bo->va));" from kernel radeon driver. So it seems to leak
some buffers. 

I will attach the full log tomorrow, it is mess-up with my traces atm but the
essential is above I hope.

So I have 4 questions:
 1: Can an application causes a "ring 0 stalled" ? or is it a driver bug
(kernel side or mesa/drm or xserver) ?
 2: About these atombios failures, does it mean that it fails to load the gpu
microcode/firmware ?
 3: Does it try to do a gpu softreset because I added R600_DEBUG=check_vm ? Or
this one just help to flush the traces on vm fault (like mentioned in a commit
msg related to that env var in mesa) ?
 4: For the deallocation failure / leak above (radeon_ttm_bo_destroy warning),
does it mean the memory is lost until next reboot or does a gpu soft reset
allow to recover these leaks ? 

Thx !

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 2992 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  parent reply	other threads:[~2017-04-06 16:27 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-30 10:59 [Bug 100465] Hard lockup with radeonsi driver on FirePro W600, W9000 and W9100 bugzilla-daemon
2017-03-30 11:00 ` bugzilla-daemon
2017-03-30 12:31 ` bugzilla-daemon
2017-03-31  1:11 ` bugzilla-daemon
2017-03-31  2:21 ` bugzilla-daemon
2017-03-31  9:04 ` bugzilla-daemon
2017-03-31 14:49 ` bugzilla-daemon
2017-04-02 13:18 ` bugzilla-daemon
2017-04-03  9:19 ` bugzilla-daemon
2017-04-04 17:03 ` bugzilla-daemon
2017-04-06 16:27 ` bugzilla-daemon [this message]
2017-04-06 16:54 ` bugzilla-daemon
2017-04-10  7:44 ` bugzilla-daemon
2017-04-10 10:03 ` bugzilla-daemon
2017-04-10 22:25 ` bugzilla-daemon
2017-04-10 22:27 ` bugzilla-daemon
2017-04-10 22:28 ` bugzilla-daemon
2017-04-10 22:29 ` bugzilla-daemon
2017-04-10 22:56 ` bugzilla-daemon
2017-04-10 22:56 ` bugzilla-daemon
2017-04-18 14:23 ` bugzilla-daemon
2017-04-18 14:23 ` bugzilla-daemon
2017-04-18 14:23 ` bugzilla-daemon
2017-04-18 14:23 ` bugzilla-daemon
2017-04-18 15:19 ` bugzilla-daemon
2017-04-19 23:01 ` bugzilla-daemon
2017-04-19 23:04 ` bugzilla-daemon
2017-04-19 23:36 ` bugzilla-daemon
2019-11-19  9:27 ` bugzilla-daemon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-100465-502-OKVaiog0pr@http.bugs.freedesktop.org/ \
    --to=bugzilla-daemon@freedesktop.org \
    --cc=dri-devel@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.