90d27a1 moved the lock before this error path but forgot to add an
unlock here.
Fixes: 90d27a1b180e51ef0713 ("drm/i915/gvt: fix deadlock in workload_thread")
Cc: Pei Zhang
Cc: Zhenyu Wang
Signed-off-by: Eric Engestrom
---
drivers/gpu/drm/i915/gvt/scheduler.c | 1 +
1 file changed, 1
signee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161204/0e88cb31/attachment.html>
because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161204/cab7d810/attachment.html>
org/archives/dri-devel/attachments/20161204/eda53ae6/attachment.html>
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161204/88b9a1c0/attachment.html>
gnee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161204/632f54aa/attachment.html>
this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161204/33701d32/attachment-0001.html>
s that you can close this ticket as unreproducible.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161204/7be4d6c6/attachment.html>
attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161204/c8c03c70/attachment.html>
Intel Corporation
-- next part --
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 37281 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161204/940c6263/attachment-0001.gz>
for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161204/71d1b3da/attachment.html>
vel/attachments/20161204/a122daf8/attachment.html>
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161204/78cd7511/attachment.html>
art --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161204/bd60880c/attachment.html>
On 11/30/2016 6:23 PM, Jason Gunthorpe wrote:
>> and O_DIRECT operations that access GPU memory.
> This goes through user space so there is still a VMA..
>
>> Also, HMM's migration between two GPUs could use peer to peer in the
>> kernel, although that is intended to be handled by the GPU driver
is in a part specific to RS690 chip so.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161204/99af7160/attachment.html>
On 11/30/2016 8:01 PM, Logan Gunthorpe wrote:
>
>
> On 30/11/16 09:23 AM, Jason Gunthorpe wrote:
>>> Two cases I can think of are RDMA access to an NVMe device's controller
>>> memory buffer,
>>
>> I'm not sure on the use model there..
>
> The NVMe fabrics stuff could probably make use of this.
On 11/30/2016 7:28 PM, Serguei Sagalovitch wrote:
> On 2016-11-30 11:23 AM, Jason Gunthorpe wrote:
>>> Yes, that sounds fine. Can we simply kill the process from the GPU driver?
>>> Or do we need to extend the OOM killer to manage GPU pages?
>> I don't know..
> We could use send_sig_info to send
Hi All
This has been a great thread (thanks to Alex for kicking it off) and I
wanted to jump in and maybe try and put some summary around the
discussion. I also wanted to propose we include this as a topic for LFS/MM
because I think we need more discussion on the best way to add this
>>
>> The NVMe fabrics stuff could probably make use of this. It's an
>> in-kernel system to allow remote access to an NVMe device over RDMA. So
>> they ought to be able to optimize their transfers by DMAing directly to
>> the NVMe's CMB -- no userspace interface would be required but there
>>
Hi Linus,
I awoke this morning to realise I hadn't sent my -fixes pull, I then
discovered the office where my build and sign
tags machine had a power cut, and since nobody will be in until
tomorrow I can't restart my desktop. So this tag is
unsigned due to that and the realisation I don't keep my
crubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161204/6babb43c/attachment.html>
of this issue so it can finally be fixed?
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161204/bd0bea10/attachment-0001.html>
https://bugzilla.kernel.org/show_bug.cgi?id=188091
--- Comment #8 from Greg White ---
Created attachment 246801
--> https://bugzilla.kernel.org/attachment.cgi?id=246801=edit
Patch against atombios_dp.c
Seems to fix the problem locally. I have no idea if it's correct or not, but
it may help
https://bugzilla.kernel.org/show_bug.cgi?id=188091
--- Comment #7 from Greg White ---
I have attached a patch which seems to fix the problem here. Maybe it will be
helpful?
--
You are receiving this mail because:
You are watching the assignee of the bug.
25 matches
Mail list logo
