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
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,
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
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
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
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
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
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
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:
>
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,
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
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
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
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
,
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 Official Use Only
; 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 weeks ago drm: Don't free jobs
Cc: dri-de...@lists.freedesktop.org ;
amd-gfx@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 which also wasn't
, Alexander
*Cc:* dri-de...@lists.freedesktop.org
; amd-gfx@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
eedesktop.org; amd-gfx@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.
&
...@lists.freedesktop.org ;
amd-gfx@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 12/2
...@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 already
>Cc: dri-de...@lists.freedesktop.org; amd-gfx@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
@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 mentioned
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
: [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, 2019 12:51 PM
&g
[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, 2019 12:51 PM
>Cc: dri-de...@lists.freedesktop.org; amd-gfx@lists.freedesktop.org;
31 matches
Mail list logo
