Hi Lucas,
Thank you for following up on this. Some things have slowed down,
given the world pandemic we've been experiencing this year.
I've had the design ready and half of it implemented and committed
into a branch. Just as per what I wrote earlier this year on this thread.
I need to finish th
Christian, I would want this very much but unfortunately I am on a strict
schedule for an internal project currently and hence will not be able to
actively participate. I will do my best to answer any questions Luben might have
about current implementation.
Andrey
On 7/21/20 9:39 AM, Christia
Luben had a good idea how to tackle the whole job handling.
Andrey/Lucas can you work with Luben to get this cleaned up because
there are a lot of requirements on this which not only come from AMD.
Thanks,
Christian.
Am 21.07.20 um 15:36 schrieb Andrey Grodzovsky:
Lucas, Luben picked the work
Lucas, Luben picked the work on this a few month ago as I was diverted to a
different project.
Luben, can you update Lucas please ?
Andrey
On 7/21/20 7:03 AM, Lucas Stach wrote:
It seems we all dropped the ball on this one. I believe this is still
an open issue. Has there been any progress fr
Hi Andrey,
Am Mittwoch, den 12.02.2020, 11:33 -0500 schrieb Andrey Grodzovsky:
> On 2/11/20 7:53 PM, Luben Tuikov wrote:
> > On 2020-02-11 4:27 p.m., Andrey Grodzovsky wrote:
> > > On 2/11/20 10:55 AM, Andrey Grodzovsky wrote:
> > > > On 2/10/20 4:50 PM, Luben Tuikov wrote:
> > > > > Hi Lucas,
> >
On 2/11/20 7:53 PM, Luben Tuikov wrote:
On 2020-02-11 4:27 p.m., Andrey Grodzovsky wrote:
On 2/11/20 10:55 AM, Andrey Grodzovsky wrote:
On 2/10/20 4:50 PM, Luben Tuikov wrote:
Hi Lucas,
Thank you for bringing awareness of this issue, publicly.
As soon as this patch showed up back in Novembe
On 2020-02-11 4:27 p.m., Andrey Grodzovsky wrote:
>
> On 2/11/20 10:55 AM, Andrey Grodzovsky wrote:
>> On 2/10/20 4:50 PM, Luben Tuikov wrote:
>>> Hi Lucas,
>>>
>>> Thank you for bringing awareness of this issue, publicly.
>>>
>>> As soon as this patch showed up back in November of 2019,
>>> I obj
On 2/11/20 10:55 AM, Andrey Grodzovsky wrote:
On 2/10/20 4:50 PM, Luben Tuikov wrote:
Hi Lucas,
Thank you for bringing awareness of this issue, publicly.
As soon as this patch showed up back in November of 2019,
I objected to it, privately.
I didn't find this objection in my mail actually
On 2/10/20 4:50 PM, Luben Tuikov wrote:
Hi Lucas,
Thank you for bringing awareness of this issue, publicly.
As soon as this patch showed up back in November of 2019,
I objected to it, privately.
I didn't find this objection in my mail actually
I suggested to instead use a _list_ to store
Hi Lucas,
Thank you for bringing awareness of this issue, publicly.
As soon as this patch showed up back in November of 2019,
I objected to it, privately.
I suggested to instead use a _list_ to store the "state" of
all jobs of the same state. Then, at any time, timeout interrupt
or whatever, we
Lucas - Ping on my question and also I attached this temporary solution
for etnaviv to clarify my point. If that something acceptable for now at
least i can do the same for v3d where it requires a bit more code changes.
Andrey
On 2/6/20 10:49 AM, Andrey Grodzovsky wrote:
Well a revert would b
On Thu, Feb 6, 2020 at 3:51 PM Christian König wrote:
>
> Am 06.02.20 um 15:49 schrieb Alex Deucher:
> > On Thu, Feb 6, 2020 at 6:50 AM Christian König
> > wrote:
> >> Am 06.02.20 um 12:10 schrieb Lucas Stach:
> >>> Hi all,
> >>>
> >>> On Mi, 2020-02-05 at 19:24 +0100, Lucas Stach wrote:
> H
On 2/6/20 9:51 AM, Christian König wrote:
Am 06.02.20 um 15:49 schrieb Alex Deucher:
On Thu, Feb 6, 2020 at 6:50 AM Christian König
wrote:
Am 06.02.20 um 12:10 schrieb Lucas Stach:
Hi all,
On Mi, 2020-02-05 at 19:24 +0100, Lucas Stach wrote:
Hi Andrey,
This commit breaks all drivers, whic
Am 06.02.20 um 15:49 schrieb Alex Deucher:
On Thu, Feb 6, 2020 at 6:50 AM Christian König
wrote:
Am 06.02.20 um 12:10 schrieb Lucas Stach:
Hi all,
On Mi, 2020-02-05 at 19:24 +0100, Lucas Stach wrote:
Hi Andrey,
This commit breaks all drivers, which may bail out of the timeout
processing as
On Thu, Feb 6, 2020 at 6:50 AM Christian König
wrote:
>
> Am 06.02.20 um 12:10 schrieb Lucas Stach:
> > Hi all,
> >
> > On Mi, 2020-02-05 at 19:24 +0100, Lucas Stach wrote:
> >> Hi Andrey,
> >>
> >> This commit breaks all drivers, which may bail out of the timeout
> >> processing as they wish to e
Am 06.02.20 um 12:10 schrieb Lucas Stach:
Hi all,
On Mi, 2020-02-05 at 19:24 +0100, Lucas Stach wrote:
Hi Andrey,
This commit breaks all drivers, which may bail out of the timeout
processing as they wish to extend the timeout (etnaviv, v3d).
Those drivers currently just return from the timeou
Hi all,
On Mi, 2020-02-05 at 19:24 +0100, Lucas Stach wrote:
> Hi Andrey,
>
> This commit breaks all drivers, which may bail out of the timeout
> processing as they wish to extend the timeout (etnaviv, v3d).
>
> Those drivers currently just return from the timeout handler before
> calling drm_sc
Hi Andrey,
This commit breaks all drivers, which may bail out of the timeout
processing as they wish to extend the timeout (etnaviv, v3d).
Those drivers currently just return from the timeout handler before
calling drm_sched_stop(), which means with this commit applied we are
removing the first j
,
Christian ; steven.pr...@arm.com
Subject: Re: [PATCH v4] drm/scheduler: Avoid accessing freed bad job.
Turns out Steven's patch was already in so i just cherry-picked the change from
drm-next-misc
Emily - it's in.
Andrey
On 12/3/19 2:59 PM, Deucher, Alexander wrote:
[AMD Officia
esktop.org
; Koenig, Christian
; steven.pr...@arm.com
*Subject:* Re: [PATCH v4] drm/scheduler: Avoid accessing freed bad job.
I don't think i can apply this patch 'as is' as this has dependency on
patch by Steven which also wasn't applied yet - 588b982 Steven
Price 6 wee
Cc: dri-devel@lists.freedesktop.org ;
amd-...@lists.freedesktop.org ; Koenig,
Christian ; steven.pr...@arm.com
Subject: Re: [PATCH v4] drm/scheduler: Avoid accessing freed bad job.
I don't think i can apply this patch 'as is' as this has dependency on patch by
Steven wh
o:* Deng, Emily ; Deucher, Alexander
*Cc:* dri-devel@lists.freedesktop.org
; amd-...@lists.freedesktop.org
; Koenig, Christian
; steven.pr...@arm.com
*Subject:* Re: [PATCH v4] drm/scheduler: Avoid accessing freed bad job.
Yes - Christian just pushed it to drm-next-misc - I guess Alex/Christian
didn&
eedesktop.org; amd-...@lists.freedesktop.org; Koenig,
>Christian ; steven.pr...@arm.com
>Subject: Re: [PATCH v4] drm/scheduler: Avoid accessing freed bad job.
>
>Yes - Christian just pushed it to drm-next-misc - I guess Alex/Christian
>didn't pull
>to amd-staging-drm-next y
@lists.freedesktop.org ;
amd-...@lists.freedesktop.org ; Koenig,
Christian ; steven.pr...@arm.com
Subject: Re: [PATCH v4] drm/scheduler: Avoid accessing freed bad job.
Yes - Christian just pushed it to drm-next-misc - I guess Alex/Christian
didn't pull to amd-staging-drm-next yet.
Andrey
On
en.pr...@arm.com
Subject: Re: [PATCH v4] drm/scheduler: Avoid accessing freed bad job.
Ping
Andrey
On 11/25/19 3:51 PM, Andrey Grodzovsky wrote:
Problem:
Due to a race between drm_sched_cleanup_jobs in sched thread and
drm_sched_job_timedout in timeout work there is a possiblity that bad
job was al
t;Cc: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org; Koenig,
>Christian ; steven.pr...@arm.com
>Subject: RE: [PATCH v4] drm/scheduler: Avoid accessing freed bad job.
>
>[AMD Official Use Only - Internal Distribution Only]
>
>Reviewed-by: Emily Deng
>
>>-Original Messa
ly
>; steven.pr...@arm.com
>Subject: Re: [PATCH v4] drm/scheduler: Avoid accessing freed bad job.
>
>Ping
>
>Andrey
>
>On 11/25/19 3:51 PM, Andrey Grodzovsky wrote:
>> Problem:
>> Due to a race between drm_sched_cleanup_jobs in sched thread and
>> drm_sched_jo
Ping
Andrey
On 11/25/19 3:51 PM, Andrey Grodzovsky wrote:
Problem:
Due to a race between drm_sched_cleanup_jobs in sched thread and
drm_sched_job_timedout in timeout work there is a possiblity that
bad job was already freed while still being accessed from the
timeout thread.
Fix:
Instead of ju
amd-...@lists.freedesktop.org ; Koenig,
Christian ; steven.pr...@arm.com
; Deucher, Alexander
Subject: Re: [PATCH v4] drm/scheduler: Avoid accessing freed bad job.
Christian asked to submit it to drm-misc instead of our drm-next to avoid later
conflicts with Steven's patch which he mention
t: RE: [PATCH v4] drm/scheduler: Avoid accessing freed bad job.
[AMD Official Use Only - Internal Distribution Only]
Hi Andrey,
Seems you didn't submit this patch?
Best wishes
Emily Deng
>-Original Message-
>From: Andrey Grodzovsky
>Sent: Monday, November 25, 201
s.freedesktop.org; Koenig,
>Christian ; Deng, Emily
>; steven.pr...@arm.com; Grodzovsky, Andrey
>
>Subject: [PATCH v4] drm/scheduler: Avoid accessing freed bad job.
>
>Problem:
>Due to a race between drm_sched_cleanup_jobs in sched thread and
>drm_sched_job_timedout in timeou
Problem:
Due to a race between drm_sched_cleanup_jobs in sched thread and
drm_sched_job_timedout in timeout work there is a possiblity that
bad job was already freed while still being accessed from the
timeout thread.
Fix:
Instead of just peeking at the bad job in the mirror list
remove it from th
32 matches
Mail list logo
