From: bugzilla-daemon@freedesktop.org
To: dri-devel@lists.freedesktop.org
Subject: [Bug 100712] ring 0 stalled after bytes_moved_threshold reached - Cap Verde - HD 7770
Date: Tue, 18 Apr 2017 15:14:55 +0000 [thread overview]
Message-ID: <bug-100712-502@http.bugs.freedesktop.org/> (raw)
[-- Attachment #1.1: Type: text/plain, Size: 1806 bytes --]
https://bugs.freedesktop.org/show_bug.cgi?id=100712
Bug ID: 100712
Summary: ring 0 stalled after bytes_moved_threshold reached -
Cap Verde - HD 7770
Product: DRI
Version: DRI git
Hardware: Other
OS: All
Status: NEW
Severity: normal
Priority: medium
Component: DRM/Radeon
Assignee: dri-devel@lists.freedesktop.org
Reporter: julien.isorce@gmail.com
Kernel 4.9 from
https://cgit.freedesktop.org/~agd5f/linux/log/?h=amd-staging-4.9 and latest
mesa. (same result with drm-next-4.12 branch)
Same result with kernel 4.8 and mesa 12.0.6.
In kernel radeon_object.c::radeon_bo_list_validate, once "bytes_moved >
bytes_moved_threshold" is reached (this is the case for 850 bo in the same
list_for_each_entry loop), I can see that radeon_ib_schedule emits a fence that
it takes more than the radeon.lockup_timeout to be signaled.
In radeon_fence_activity, I checked that the "last_emitted" is the seq number
for this last emited fence. And last_seq is equal to last_emitted-1.
Then the next call to ttm_wait_bo blocks (15 * HZ > radeon.lockup_timeout)
until gpu lockup which leads to a gpu reset.
Also it seems the fence is signaled by swapper after more than 10 seconds but
it is too late. I requires to reduce the "15" param above to 4 to see that.
Is it normal that radeon_bo_list_validate still tries to move the bo if
bytes_moved_threshold is reached ? Indeed ttm_bo_validate is always called (it
blits from vram to vram).
Is it also normal that ttm_bo_validate is called with evict flag as true once
bytes_moved_threshold is reached ?
--
You are receiving this mail because:
You are the assignee for the bug.
[-- Attachment #1.2: Type: text/html, Size: 3220 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
next reply other threads:[~2017-04-18 15:14 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-18 15:14 bugzilla-daemon [this message]
2017-04-18 15:15 ` [Bug 100712] ring 0 stalled after bytes_moved_threshold reached - Cap Verde - HD 7770 bugzilla-daemon
2017-04-18 15:15 ` bugzilla-daemon
2017-04-18 15:16 ` bugzilla-daemon
2017-04-19 3:48 ` bugzilla-daemon
2017-04-19 12:03 ` bugzilla-daemon
2017-04-20 15:15 ` bugzilla-daemon
2017-04-20 15:15 ` [Bug 100712] ring 0 stalled after bytes_moved_threshold reached - CAPVERDE/HD7770 - TAHITI/W9000 bugzilla-daemon
2017-04-20 15:23 ` bugzilla-daemon
2017-04-24 11:02 ` bugzilla-daemon
2019-11-19 9:28 ` 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-100712-502@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.