On 01/10/2020 16:49, Boris Brezillon wrote:
On Thu, 1 Oct 2020 15:49:39 +0100
Steven Price wrote:
On 01/10/2020 15:01, Boris Brezillon wrote:
If more than two or more jobs end up timeout-ing concurrently, only one
of them (the one attached to the scheduler acquiring the lock) is fully
handled
On Thu, 1 Oct 2020 15:49:39 +0100
Steven Price wrote:
> On 01/10/2020 15:01, Boris Brezillon wrote:
> > If more than two or more jobs end up timeout-ing concurrently, only one
> > of them (the one attached to the scheduler acquiring the lock) is fully
> > handled. The other one remains in a dangl
On Thu, 1 Oct 2020 15:49:39 +0100
Steven Price wrote:
> On 01/10/2020 15:01, Boris Brezillon wrote:
> > If more than two or more jobs end up timeout-ing concurrently, only one
> > of them (the one attached to the scheduler acquiring the lock) is fully
> > handled. The other one remains in a dangl
On 01/10/2020 15:01, Boris Brezillon wrote:
If more than two or more jobs end up timeout-ing concurrently, only one
of them (the one attached to the scheduler acquiring the lock) is fully
handled. The other one remains in a dangling state where it's no longer
part of the scheduling queue, but sti
If more than two or more jobs end up timeout-ing concurrently, only one
of them (the one attached to the scheduler acquiring the lock) is fully
handled. The other one remains in a dangling state where it's no longer
part of the scheduling queue, but still blocks something in scheduler
thus leading
Oops, the prefix should be "drm/panfrost", will fix that in v2.
On Thu, 1 Oct 2020 16:01:43 +0200
Boris Brezillon wrote:
> If more than two or more jobs end up timeout-ing concurrently, only one
> of them (the one attached to the scheduler acquiring the lock) is fully
> handled. The other one r
