From: "Christian König" <christian.koenig@amd.com>
To: Maarten Lankhorst <maarten.lankhorst@canonical.com>, <airlied@linux.ie>
Cc: <thellstrom@vmware.com>, <nouveau@lists.freedesktop.org>,
<linux-kernel@vger.kernel.org>, <dri-devel@lists.freedesktop.org>,
<bskeggs@redhat.com>, <alexander.deucher@amd.com>
Subject: Re: [PATCH 09/19] drm/radeon: handle lockup in delayed work, v2
Date: Mon, 4 Aug 2014 19:04:46 +0200 [thread overview]
Message-ID: <53DFBD2E.5070001@amd.com> (raw)
In-Reply-To: <53DFA210.2020603@canonical.com>
Am 04.08.2014 um 17:09 schrieb Maarten Lankhorst:
> op 04-08-14 17:04, Christian König schreef:
>> Am 04.08.2014 um 16:58 schrieb Maarten Lankhorst:
>>> op 04-08-14 16:45, Christian König schreef:
>>>> Am 04.08.2014 um 16:40 schrieb Maarten Lankhorst:
>>>>> op 04-08-14 16:37, Christian König schreef:
>>>>>>> It'a pain to deal with gpu reset.
>>>>>> Yeah, well that's nothing new.
>>>>>>
>>>>>>> I've now tried other solutions but that would mean reverting to the old style during gpu lockup recovery, and only running the delayed work when !lockup.
>>>>>>> But this meant that the timeout was useless to add. I think the cleanest is keeping the v2 patch, because potentially any waiting code can be called during lockup recovery.
>>>>>> The lockup code itself should never call any waiting code and V2 doesn't seem to handle a couple of cases correctly either.
>>>>>>
>>>>>> How about moving the fence waiting out of the reset code?
>>>>> What cases did I miss then?
>>>>>
>>>>> I'm curious how you want to move the fence waiting out of reset, when there are so many places that could potentially wait, like radeon_ib_get can call radeon_sa_bo_new which can do a wait, or radeon_ring_alloc that can wait on radeon_fence_wait_next, etc.
>>>> The IB test itself doesn't needs to be protected by the exclusive lock. Only everything between radeon_save_bios_scratch_regs and radeon_ring_restore.
>>> I'm not sure about that, what do you want to do if the ring tests fail? Do you have to retake the exclusive lock?
>> Just set need_reset again and return -EAGAIN, that should have mostly the same effect as what we are doing right now.
> Yeah, except for the locking the ttm delayed workqueue, but that bool should be easy to save/restore.
> I think this could work.
Actually you could activate the delayed workqueue much earlier as well.
Thinking more about it that sounds like a bug in the current code,
because we probably want the workqueue activated before waiting for the
fence.
Christian.
>
> ~Maarten
>
next prev parent reply other threads:[~2014-08-04 17:05 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-31 15:32 [PATCH 01/19] fence: add debugging lines to fence_is_signaled for the callback Maarten Lankhorst
2014-07-31 15:32 ` [PATCH 02/19] drm/ttm: add interruptible parameter to ttm_eu_reserve_buffers Maarten Lankhorst
2014-07-31 15:33 ` [PATCH 03/19] drm/ttm: kill off some members to ttm_validate_buffer Maarten Lankhorst
2014-07-31 15:33 ` [PATCH 04/19] drm/nouveau: add reservation to nouveau_gem_ioctl_cpu_prep Maarten Lankhorst
2014-07-31 15:33 ` [PATCH 05/19] drm/nouveau: require reservations for nouveau_fence_sync and nouveau_bo_fence Maarten Lankhorst
2014-07-31 15:33 ` [PATCH 06/19] drm/ttm: call ttm_bo_wait while inside a reservation Maarten Lankhorst
2014-07-31 15:33 ` [PATCH 07/19] drm/ttm: kill fence_lock Maarten Lankhorst
2014-07-31 15:33 ` [PATCH 08/19] drm/nouveau: rework to new fence interface Maarten Lankhorst
2014-07-31 15:33 ` [PATCH 09/19] drm/radeon: handle lockup in delayed work, v2 Maarten Lankhorst
2014-08-01 16:35 ` Christian König
2014-08-01 17:46 ` Maarten Lankhorst
2014-08-04 8:36 ` Christian König
2014-08-04 8:55 ` Maarten Lankhorst
2014-08-04 11:57 ` Christian König
2014-08-04 13:34 ` Maarten Lankhorst
2014-08-04 14:37 ` Christian König
2014-08-04 14:40 ` Maarten Lankhorst
2014-08-04 14:45 ` Christian König
2014-08-04 14:58 ` Maarten Lankhorst
2014-08-04 15:04 ` Christian König
2014-08-04 15:09 ` Maarten Lankhorst
2014-08-04 17:04 ` Christian König [this message]
2014-08-05 8:16 ` Daniel Vetter
2014-08-05 9:34 ` Maarten Lankhorst
2014-07-31 15:33 ` [PATCH 10/19] drm/radeon: add timeout argument to radeon_fence_wait_seq Maarten Lankhorst
2014-07-31 15:33 ` [PATCH 11/19] drm/radeon: use common fence implementation for fences, v2 Maarten Lankhorst
2014-07-31 15:34 ` [PATCH 12/19] drm/qxl: rework to new fence interface Maarten Lankhorst
2014-07-31 15:34 ` [PATCH 13/19] drm/vmwgfx: get rid of different types of fence_flags entirely Maarten Lankhorst
2014-07-31 15:34 ` [PATCH 14/19] drm/vmwgfx: rework to new fence interface Maarten Lankhorst
2014-07-31 15:34 ` [PATCH 15/19] drm/ttm: flip the switch, and convert to dma_fence Maarten Lankhorst
2014-07-31 15:34 ` [PATCH 16/19] drm/nouveau: use rcu in nouveau_gem_ioctl_cpu_prep Maarten Lankhorst
2014-07-31 15:34 ` [PATCH 17/19] drm/radeon: use rcu waits in some ioctls Maarten Lankhorst
2014-07-31 15:34 ` [PATCH 18/19] drm/vmwgfx: use rcu in vmw_user_dmabuf_synccpu_grab Maarten Lankhorst
2014-07-31 15:34 ` [PATCH 19/19] drm/ttm: use rcu in core ttm Maarten Lankhorst
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=53DFBD2E.5070001@amd.com \
--to=christian.koenig@amd.com \
--cc=airlied@linux.ie \
--cc=alexander.deucher@amd.com \
--cc=bskeggs@redhat.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maarten.lankhorst@canonical.com \
--cc=nouveau@lists.freedesktop.org \
--cc=thellstrom@vmware.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome