On Wednesday, February 3, 2016 1:24:49 PM EST Christian König wrote:
> Am 31.01.2016 um 19:50 schrieb Matthew Dawson:
> > On Sunday, January 24, 2016 10:49:00 AM EST Christian König wrote:
> >> Am 24.01.2016 um 07:18 schrieb Matthew Dawson:
> >>> When the radeon dr
he default 10s from radeon_wait_timeout was
too long. A timeout of 100ms was tested and found to be too short.
- Changed radeon_fence_wait_timeout to behave more like fence_wait_timeout.
Signed-off-by: Matthew Dawson
---
drivers/gpu/drm/radeon/cik.c | 11 --
drivers/gpu/
On Sunday, January 24, 2016 10:49:00 AM EST Christian König wrote:
> Am 24.01.2016 um 07:18 schrieb Matthew Dawson:
> > When the radeon driver resets a gpu, it attempts to test whether all the
> > rings can successfully handle an IB. If these rings fail to respond, the
> &
Found with lockdep while testing gpu reset.
Signed-off-by: Matthew Dawson
---
drivers/gpu/drm/radeon/radeon_gem.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/radeon/radeon_gem.c
b/drivers/gpu/drm/radeon/radeon_gem.c
index 3dcc573..e26c963 100644
--- a/drivers/gpu/drm
radeon_fence_wait_timeout, that behaves like
radeon_fence_wait except allowing a different timeout value to be passed to
radeon_fence_wait_seq_timeout.
Signed-off-by: Matthew Dawson
---
drivers/gpu/drm/radeon/cik_sdma.c | 3 ++-
drivers/gpu/drm/radeon/r100.c | 3 ++-
driv
On Sunday, January 17, 2016 2:10:06 AM EST you wrote:
> Details on testing done:
Sorry, forgot one other thing. I tried enabling the hard_reset parameter
without UVD modifications, with no change. Not sure if that helps.
Thanks,
--
Matthew
-- next part --
A non-text att
Hi all,
I'm trying to work through this bug: https://bugs.freedesktop.org/
show_bug.cgi?id=93649 . The main symptom that something has gone wrong is the
system locks up, with some process trying to reset the gpu while the gpu is
trying to be reset which deadlocks. The system still works over s
