,
Alexander ; Koenig, Christian
Cc: Xiao, Jack
Betreff: [PATCH] drm/amdgpu: only WARN freeing buffers when DMA is unavailable
Reduce waringings, only warn when DMA is unavailable.
Signed-off-by: Jack Xiao
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 3 ++-
1 file changed, 2 insertions(+), 1
An: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Koenig, Christian
; Pan, Xinhui
Betreff: [PATCH] drm/amdgpu: Make sure ttm delayed work finished
ttm_device_delayed_workqueue would reschedule itself if there is pending
BO to be destroyed. So just one flush + cancel_sync is not enough. We
Seconded, there is one include for each hardware version.
At least of hand I don't see a duplicate.
Von: Simon Ser
Gesendet: Donnerstag, 30. September 2021 12:17
An: Guo Zhengkui
Cc: Deucher, Alexander ; Koenig, Christian
; Pan, Xinhui ; David Airlie
; Daniel
,
Christian.
Von: Quan, Evan
Gesendet: Donnerstag, 12. August 2021 04:42
An: Koenig, Christian ; Michel Dänzer
; Deucher, Alexander
Cc: Liu, Leo ; Zhu, James ;
amd-gfx@lists.freedesktop.org ;
dri-de...@lists.freedesktop.org
Betreff: RE: [PATCH 2/2] drm/amdgpu
. August 2021 18:52
An: Deucher, Alexander ; Koenig, Christian
Cc: Liu, Leo ; Zhu, James ;
amd-gfx@lists.freedesktop.org ;
dri-de...@lists.freedesktop.org
Betreff: [PATCH 2/2] drm/amdgpu: Use mod_delayed_work in JPEG/UVD/VCE/VCN
ring_end_use hooks
From: Michel Dänzer
In contrast
Reviewed-by: Christian König
Von: Daniel Gomez
Gesendet: Donnerstag, 18. März 2021 09:32
Cc: dag...@gmail.com ; Daniel Gomez ;
Deucher, Alexander ; Koenig, Christian
; David Airlie ; Daniel Vetter
; amd-gfx@lists.freedesktop.org
; dri-de
it is used correctly. The only reason it
doesn't complain here is because you use an atomic+wait_event instead of a
locking primitive.
Regards,
Christian.
Von: Li, Dennis
Gesendet: Donnerstag, 18. März 2021 09:28
An: Koenig, Christian ; amd-gfx
Reviewed-by: Christian König
Von: Sharma, Shashank
Gesendet: Samstag, 13. Februar 2021 17:37
An: amd-gfx@lists.freedesktop.org
Cc: Sharma, Shashank ; Koenig, Christian
; Deucher, Alexander
Betreff: [PATCH 2/2] drm/amdgpu: clean-up unused variable
Variable 'bp
on the exported BO.
Regards,
Christian.
Von: Sharma, Shashank
Gesendet: Samstag, 13. Februar 2021 17:37
An: amd-gfx@lists.freedesktop.org
Cc: Sharma, Shashank ; Koenig, Christian
; Deucher, Alexander
Betreff: [PATCH 1/2] drm/amdgpu: Set GTT_USWC flag to enable freesync
Yes, that's a known issue. Patch for the revert is already underway.
Christian.
Am 12.09.2020 10:43 schrieb Borislav Petkov :
Hi,
this patch breaks X on my box - it is fully responsive and I can log in
into it from another machine but both monitors are black and show this:
"The current input
Am 09.09.2020 07:29 schrieb Huacai Chen :
Though RADEON_GEM_GTT_WC is initially used for GTT, but this flag is
bound to drm_arch_can_wc_memory(), and if arch doesn't support WC, then
VRAM should not use WC.
NAK, If System memory supports WC is completely independent from the VRAM BAR.
Am 14.08.2020 17:53 schrieb Alex Deucher :
On Fri, Aug 14, 2020 at 11:22 AM Christian König
wrote:
>
> Hey Thomas & Alex,
>
> well the TTM and Nouveau changes look good to me, but this completely
> broke amdgpu.
>
> Alex any idea what is going on here?
What's broken in amdgpu? There shouldn't
NAK, we also use the entity context number for debugging.
Additional to this the entities should not need any additional resources. So
the functions are only initializing fields.
Regards,
Christian.
Am 06.08.2020 18:06 schrieb "Wang, Kevin(Yang)" :
the entity isn't needed when vm use cpu to
Sure.
Christian.
Am 29.07.2020 17:30 schrieb "Deucher, Alexander" :
[AMD Public Use]
Christian, Can you cc stable when you apply it to drm-misc?
Alex
From: Kuehling, Felix
Sent: Wednesday, July 29, 2020 10:15 AM
To: Koenig, Christian
Am 09.06.2020 18:37 schrieb "Grodzovsky, Andrey" :
On 6/5/20 2:40 PM, Christian König wrote:
> Am 05.06.20 um 16:29 schrieb Andrey Grodzovsky:
>>
>> On 5/11/20 2:45 AM, Christian König wrote:
>>> Am 09.05.20 um 20:51 schrieb Andrey Grodzovsky:
Signed-off-by: Andrey Grodzovsky
---
Am 06.05.2020 18:00 schrieb Alex Deucher :
On Wed, May 6, 2020 at 10:27 AM Zheng Bin wrote:
>
> Zheng Bin (14):
> drm/radeon: remove comparison to bool in btc_dpm.c
> drm/radeon: remove comparison to bool in ci_dpm.c
> drm/radeon: remove comparison to bool in ni_dpm.c
> drm/radeon:
every
engine, why we need a GL2C invalidate before IB execute ?
_
Monk Liu|GPU Virtualization Team |AMD
[sig-cloud-gpu]
From: Koenig, Christian
Sent: Wednesday, April 29, 2020 5:38 PM
To: Liu, Monk ; Marek Olšák ; amd-gfx
mailing list
Subject: Re: drm/amd
.
Am 14.04.2020 16:35 schrieb "Deucher, Alexander" :
[AMD Public Use]
If this causes an issue, any access to vram via the BAR could cause an issue.
Alex
From: amd-gfx on behalf of Russell,
Kent
Sent: Tuesday, April 14, 2020 10:19 AM
To: Koenig, Chris
Am 10.04.2020 12:58 schrieb "Pan, Xinhui" :
The delayed delete list is per device which might be very huge. And in
a heavy workload test, the list might always not be empty. That will
trigger any RCU stall warnings or softlockups in non-preemptible kernels
Lets do break out the loops in that
Am 26.03.2020 07:45 schrieb "Pan, Xinhui" :
> 2020年3月26日 14:36，Koenig, Christian 写道：
>
>
>
> Am 26.03.2020 07:15 schrieb "Pan, Xinhui" :
>
>
> > 2020年3月26日 13:38，Koenig, Christian 写道：
> >
> > Yeah that's on my TODO list for quite a
Am 26.03.2020 07:15 schrieb "Pan, Xinhui" :
> 2020年3月26日 13:38，Koenig, Christian 写道：
>
> Yeah that's on my TODO list for quite a while as well.
>
> But we even need three IB pools. One very small for the IB tests, one for
> direct VM updates and one for the rest.
Yeah that's on my TODO list for quite a while as well.
But we even need three IB pools. One very small for the IB tests, one for
direct VM updates and one for the rest.
So please make the pool a parameter to ib_get() and not the hack you have below.
Thanks,
Christian.
Am 26.03.2020 03:02
Hi guys,
thanks for pointing this out Nirmoy.
Yeah, could be that I forgot to commit the patch. Currently I don't know at
which end of the chaos I should start to clean up.
Christian.
Am 25.03.2020 12:09 schrieb "Das, Nirmoy" :
Hi Xinhui,
Can you please check if you can reproduce the crash
Good catch! mem.size is actually the backing store size (usually in pages).
Patch is Acked-by: Christian König
Am 25.03.2020 11:19 schrieb "Wang, Kevin(Yang)" :
the HPD bo size calculation error.
the "mem.size" can't present actual BO size all time.
Signed-off-by: Kevin Wang
---
Correct, yes.
For example if you have a 16GB VRAM Vega10 in a system with just 4GB RAM you
can only allocate < 4GB VRAM (actually more like ~3GB) in a single BO.
Otherwise we wouldn't be able to evacuate VRAM to system memory and disk during
suspend/resume or during memory pressure.
Regards,
Hi Nirmoy,
Am 24.02.2020 17:48 schrieb Nirmoy Das :
On reset, amdgpu can set a drm sched's ready status to false temporarily. drm
job
init will fail if all of the drm scheds are not ready for a HW IP. This patch
tries to make
kernel's internal drm job submit handle, amdgpu_job_submit() a bit
Am 25.01.2020 19:47 schrieb Andreas Messer :
When backing up a ring, validate pointer to avoid page fault.
When the drivers attempts to handle a gpu lockup, a page fault might occur
during call of radeon_ring_backup() since (*ring->next_rptr_cpu_addr) could
have invalid content:
[
Liu, Leo ; Koenig, Christian
Subject: Re: [PATCH 01/12] amdgpu: add UAPI for creating encrypted buffers
Am 15.11.19 um 04:34 schrieb Aaron Liu:
> From: Huang Rui
>
> To align the kernel uapi change from Alex:
>
> "Add a flag to the GEM_CREATE ioctl to create encrypted buffers
while in
> amdgpu_device_gpu_recover, and before calling drm_sched_stop.
>
> Best wishes
> Emily Deng
>
>
>
>> -Original Message-
>> From: Koenig, Christian
>> Sent: Friday, November 8, 2019 6:26 PM
>> To: Deng, Emily ; amd-gfx@lists.freedesktop.
patch. Even it are freed
> by main scheduler, how we could avoid main scheduler to free jobs while enter
> to function amdgpu_device_gpu_recover?
>
> Best wishes
> Emily Deng
>
>
>
>> -Original Message-
>> From: Koenig, Christian
>> Sent: Fri
x10/0x10 [amdgpu]
> [ 449.813609] ? drm_sched_job_timedout+0x44/0x90 [amd_sched]
> [ 449.814077] process_one_work+0x1fd/0x3f0
> [ 449.814417] worker_thread+0x34/0x410
> [ 449.814728] kthread+0x121/0x140
> [ 449.815004] ? process_one_work+0x3f0/0x3f0
> [ 449.
issues.
Regards,
Christian.
>
> Best wishes
> Emily Deng
>
>
>
>> -Original Message-----
>> From: Koenig, Christian
>> Sent: Friday, November 8, 2019 5:08 PM
>> To: Deng, Emily ; amd-gfx@lists.freedesktop.org
>> Subject: Re: [PATCH] drm/amdgpu: Fix
Am 08.11.19 um 09:52 schrieb Deng, Emily:
> Ping.
You need to give me at least enough time to wake up :)
>
>
> Best wishes
> Emily Deng
>
>
>
>> -Original Message-
>> From: amd-gfx On Behalf Of Deng,
>> Emily
>> Sent: Friday, November
Am 06.11.19 um 18:51 schrieb Andrey Grodzovsky:
> This reverts commit 3cdf9bd0089723c468d5f6240e54d1afa52e9a04.
>
> We will do a proper fix in next patch.
>
> Signed-off-by: Andrey Grodzovsky
The order of this one and patch #2 needs to be swapped, or otherwise we
have the bug in between those
enoir. But we have disabled
it currently because of bad interactions with IOMMU.
Christian.
>
> Oak
>
> -Original Message-
> From: Alex Deucher
> Sent: Wednesday, November 6, 2019 12:37 PM
> To: Zeng, Oak
> Cc: amd-gfx@lists.freedesktop.org; Kuehling, Felix ;
>
Am 06.11.19 um 12:35 schrieb Pan Bian:
> The reference to object fence is dropped at the end of the loop.
> However, it is dropped again outside the loop. The reference can be
> dropped immediately after calling dma_fence_wait() in the loop and
> thus the dropping operation outside the loop can be
Am 06.11.19 um 11:52 schrieb Zhu, Changfeng:
> From: changzhu
>
> The GRBM register interface is now capable of bursting 1 cycle per
> register wr->wr, wr->rd much faster than previous muticycle per
> transaction done interface. This has caused a problem where
> status registers requiring HW to
Am 06.11.19 um 10:53 schrieb Pan Bian:
> After dropping the reference of object fence in the loop, it should be
> set to NULL to protecting dropping its reference again outside the loop.
NAK, the actual bug is that we shouldn't drop the fence outside the loop
in the first place.
Just move the
Am 06.11.19 um 10:14 schrieb Pan Bian:
> The object fence is not set to NULL after its reference is dropped. As a
> result, its reference may be dropped again if error occurs after that,
> which may lead to a use after free bug. To avoid the issue, fence is
> explicitly set to NULL after dropping
Am 06.11.19 um 09:21 schrieb Zhu, Changfeng:
> From: changzhu
>
> The GRBM register interface is now capable of bursting 1 cycle per
> register wr->wr, wr->rd much faster than previous muticycle per
> transaction done interface. This has caused a problem where
> status registers requiring HW to
detail is on Jira SWDEV-201443.
>>
>> Regards,
>>
>> Eric
>>
>> On 2019-10-31 10:08 a.m., StDenis, Tom wrote:
>>> I could try it on my carrizo/polaris setup. Is there a test procedure I
>>> could folllow to trigger the changed code paths
Am 05.11.19 um 12:42 schrieb Zhu, Changfeng:
> From: changzhu
>
> The GRBM register interface is now capable of bursting 1 cycle per
> register wr->wr, wr->rd much faster than previous muticycle per
> transaction done interface. This has caused a problem where
> status registers requiring HW to
Am 05.11.19 um 12:42 schrieb Zhu, Changfeng:
> From: changzhu
>
> It needs to add warning to update firmware in gfx9
> in case that firmware is too old to have function to
> realize dummy read in cp firmware.
>
> Change-Id: I6aef94f0823138f244f1eedb62fde833dd697023
> Signed-off-by: changzhu
need 0 as mask and value, or otherwise we could
potentially wait forever.
Regards,
Christian.
>
> http://ontrack-internal.amd.com/browse/SWDEV-192660
> Jira ticket recommends to read VM_INVALIDATE_ENG*_REQ.
>
> BR,
> Changfeng.
>
> -----Original Message-
> From: Koen
Am 05.11.19 um 07:32 schrieb Zhu, Changfeng:
> From: changzhu
>
> The GRBM register interface is now capable of bursting 1 cycle per
> register wr->wr, wr->rd much faster than previous muticycle per
> transaction done interface. This has caused a problem where
> status registers requiring HW to
k the mappings of a range
in amdgpu_update_ptes() and see if you could walk the tree up if the valid flag
is not set and there are no mappings left for a page table.
Regards,
Christian.
Am 30.10.19 um 18:42 schrieb Koenig, Christian:
The vaild flag doesn't take effect in this function.
That's irrelev
lt; CHIP_VEGA10 &&
(flags & AMDGPU_PTE_VALID))...
Regards,
Eric
On 2019-10-30 12:30 p.m., Koenig, Christian wrote:
Am 30.10.2019 17:19 schrieb "Huang, JinHuiEric"
<mailto:jinhuieric.hu...@amd.com>:
I tested it that it saves a lot of vram on KFD bi
ge to what update_ptes is doing and have the
strong suspicion that the patch is simply broken.
You either free page tables which are potentially still in use or update_pte
doesn't free page tables when the valid but is not set.
Regards,
Christian.
Regards,
Eric
On 2019-10-30 11:57 a.m., Koenig,
Am 30.10.2019 16:47 schrieb "Kuehling, Felix" :
On 2019-10-30 9:52 a.m., Christian König wrote:
> Am 29.10.19 um 21:06 schrieb Huang, JinHuiEric:
>> The issue is PT BOs are not freed when unmapping VA,
>> which causes vram usage accumulated is huge in some
>> memory stress test, such as kfd big
Yeah, and exactly that's the problem :) You need a global lock covering
all schedulers.
Otherwise you end up in hell's kitchen again with taking all those locks
in the right order.
Christian.
Am 30.10.19 um 15:56 schrieb Grodzovsky, Andrey:
> Can you elaborate on what is the tricky part with
Am 30.10.19 um 10:13 schrieb S, Shirish:
> [Why]
>
> doing kthread_park()/unpark() from drm_sched_entity_fini
> while GPU reset is in progress defeats all the purpose of
> drm_sched_stop->kthread_park.
> If drm_sched_entity_fini->kthread_unpark() happens AFTER
> drm_sched_stop->kthread_park
Am 28.10.19 um 21:10 schrieb Jason Gunthorpe:
> From: Jason Gunthorpe
>
> Remove the interval tree in the driver and rely on the tree maintained by
> the mmu_notifier for delivering mmu_notifier invalidation callbacks.
>
> For some reason amdgpu has a very complicated arrangement where it tries
>
Am 28.10.19 um 21:10 schrieb Jason Gunthorpe:
> From: Jason Gunthorpe
>
> find_vma() must be called under the mmap_sem, reorganize this code to
> do the vma check after entering the lock.
>
> Further, fix the unlocked use of struct task_struct's mm, instead use
> the mm from hmm_mirror which has
Am 28.10.19 um 21:10 schrieb Jason Gunthorpe:
> From: Jason Gunthorpe
>
> The new API is an exact match for the needs of radeon.
>
> For some reason radeon tries to remove overlapping ranges from the
> interval tree, but interval trees (and mmu_range_notifier_insert)
> support overlapping ranges
ince gfx10 also realize write/wait command in a single packet after CL#1761300?
Or we can add dummy read in gmc10 by using emit_wait like Luben's way?
BR,
Changfeng.
-Original Message-----
From: Koenig, Christian
Sent: Monday, October 28, 2019 6:47 PM
To: Zhu, Changfeng ; amd-gfx@lists.freed
Am 26.10.19 um 00:41 schrieb Tuikov, Luben:
> Simplify padding calculations.
>
> v2: Comment update and spacing.
>
> Signed-off-by: Luben Tuikov
Reviewed-by: Christian König
> ---
> drivers/gpu/drm/amd/amdgpu/cik_sdma.c | 4 ++--
> drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c | 4 ++--
>
Am 26.10.19 um 00:59 schrieb Tuikov, Luben:
> The GRBM interface is now capable of bursting
> 1-cycle op per register, a WRITE followed by
> another WRITE, or a WRITE followed by a READ--much
> faster than previous muti-cycle per
> completed-transaction interface. This causes a
> problem, whereby
adev->gfx.mec_fw_write_wait = true;
> + break;
>
> So how can we deal with the firmware between mec version(402) and mec
> version(421)?
> It will realize write/wait command in CP firmware but it doesn't have dummy
> read.
>
> BR,
> Changfeng.
>
Am 26.10.19 um 00:45 schrieb Tuikov, Luben:
> On 2019-10-25 12:19 p.m., Koenig, Christian wrote:
>> Am 25.10.19 um 18:05 schrieb Alex Deucher:
>>> On Fri, Oct 25, 2019 at 2:49 AM Koenig, Christian
>>> wrote:
>>>> Am 24.10.19 um 23:16 schrieb Tuikov, Luben:
Am 25.10.19 um 23:51 schrieb Tuikov, Luben:
> On 2019-10-25 2:54 a.m., Koenig, Christian wrote:
>> Am 25.10.19 um 01:44 schrieb Tuikov, Luben:
>>> Simplify padding calculations.
>>>
>>> Signed-off-by: Luben Tuikov
>>> ---
>>>drivers/gpu/d
Am 25.10.19 um 18:05 schrieb Alex Deucher:
> On Fri, Oct 25, 2019 at 2:49 AM Koenig, Christian
> wrote:
>> Am 24.10.19 um 23:16 schrieb Tuikov, Luben:
>>> The GRBM interface is now capable of bursting
>>> 1-cycle op per register, a WRITE followed by
>>
Am 25.10.19 um 17:56 schrieb Grodzovsky, Andrey:
> On 10/25/19 11:55 AM, Koenig, Christian wrote:
>> Am 25.10.19 um 16:57 schrieb Grodzovsky, Andrey:
>>> On 10/25/19 4:44 AM, Christian König wrote:
>>>> Am 24.10.19 um 21:57 schrieb Andrey Grodzovsky:
>>>>
Am 25.10.19 um 17:35 schrieb Grodzovsky, Andrey:
On 10/25/19 5:26 AM, Koenig, Christian wrote:
Am 25.10.19 um 11:22 schrieb S, Shirish:
On 10/25/2019 2:23 PM, Koenig, Christian wrote:
amdgpu_do_asic_reset starting to resume blocks
...
amdgpu :03:00.0: couldn't schedule ib on ring
Am 25.10.19 um 16:57 schrieb Grodzovsky, Andrey:
> On 10/25/19 4:44 AM, Christian König wrote:
>> Am 24.10.19 um 21:57 schrieb Andrey Grodzovsky:
>>> Problem:
>>> When run_job fails and HW fence returned is NULL we still signal
>>> the s_fence to avoid hangs but the user has no way of knowing if
Hi Changfeng,
that won't work, you can't add this to
amdgpu_ring_emit_reg_write_reg_wait_helper or break all read triggered
registers (like the semaphore ones).
Additional to that it will never work on GFX9, since the CP firmware
there uses the integrated write/wait command and you can't add
Am 25.10.19 um 12:08 schrieb S, Shirish:
On 10/25/2019 2:56 PM, Koenig, Christian wrote:
Am 25.10.19 um 11:22 schrieb S, Shirish:
On 10/25/2019 2:23 PM, Koenig, Christian wrote:
amdgpu_do_asic_reset starting to resume blocks
...
amdgpu :03:00.0: couldn't schedule ib on ring
Am 25.10.19 um 11:22 schrieb S, Shirish:
On 10/25/2019 2:23 PM, Koenig, Christian wrote:
amdgpu_do_asic_reset starting to resume blocks
...
amdgpu :03:00.0: couldn't schedule ib on ring
[drm:amdgpu_job_run] *ERROR* Error scheduling IBs (-22)
...
amdgpu_device_ip_resume_phase2 resumed
amdgpu_do_asic_reset starting to resume blocks
...
amdgpu :03:00.0: couldn't schedule ib on ring
[drm:amdgpu_job_run] *ERROR* Error scheduling IBs (-22)
...
amdgpu_device_ip_resume_phase2 resumed gfx_v9_0
amdgpu_device_ip_resume_phase2 resumed sdma_v4_0
amdgpu_device_ip_resume_phase2
Am 25.10.19 um 01:44 schrieb Tuikov, Luben:
> Simplify padding calculations.
>
> Signed-off-by: Luben Tuikov
> ---
> drivers/gpu/drm/amd/amdgpu/cik_sdma.c | 4 ++--
> drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c | 4 ++--
> drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c | 4 ++--
>
Am 24.10.19 um 23:16 schrieb Tuikov, Luben:
> The GRBM interface is now capable of bursting
> 1-cycle op per register, a WRITE followed by
> another WRITE, or a WRITE followed by a READ--much
> faster than previous muti-cycle per
> completed-transaction interface. This causes a
> problem, whereby
Maybe say parameter instead of variable in the subject.
Am 23.10.19 um 16:35 schrieb Nirmoy Das:
> Signed-off-by: Nirmoy Das
Apart from that Acked-by: Christian König
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c | 3 +--
> drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h | 3 +--
>
Am 22.10.19 um 04:28 schrieb Chen, Guchun:
> Ras reboot debugfs node allows user one easy control to avoid
> gpu recovery hang problem and directly reboot system per card
> basis, after ras uncorrectable error happens. However, it is
> one common entry, which should get rid of ras_ctrl node and
>
Am 21.10.19 um 20:09 schrieb Navid Emamdoost:
> In the impelementation of amdgpu_fence_emit() if dma_fence_wait() fails
> and returns an errno, before returning the allocated memory for fence
> should be released.
>
> Fixes: 3d2aca8c8620 ("drm/amdgpu: fix old fence check in amdgpu_fence_emit")
>
Am 21.10.19 um 15:57 schrieb Jason Gunthorpe:
> On Sun, Oct 20, 2019 at 02:21:42PM +0000, Koenig, Christian wrote:
>> Am 18.10.19 um 22:36 schrieb Jason Gunthorpe:
>>> On Thu, Oct 17, 2019 at 04:47:20PM +, Koenig, Christian wrote:
>>> [SNIP]
>>>
&
Am 18.10.19 um 22:36 schrieb Jason Gunthorpe:
> On Thu, Oct 17, 2019 at 04:47:20PM +0000, Koenig, Christian wrote:
>
>>> get_user_pages/hmm_range_fault() and invalidate_range_start() both are
>>> called while holding mm->map_sem, so they are always seria
Am 17.10.19 um 22:12 schrieb Sylvain Munaut:
> So a bit more testing.
>
> I was using a bit of "unusual" config I guess, having 2 GPUs and some
> other pcie cards (10G, ..).
> So I simplified and went to the most standard thing I could think of,
> _just_ the RX 560 card plugged into the main PCIe
Am 17.10.19 um 16:29 schrieb Sylvain Munaut:
> Hi,
>
>
>>> I have RX 560 2G card. It's plugged into a 16x physical / 4x
>>> electrical slot of a X570 chipset motherboard with a Ryzen 3700X CPU.
>>> The hardware works fine and is stable under Windows (tested with
>>> games, benchmarks,
Sending once more as text.
Am 17.10.19 um 18:26 schrieb Yang, Philip:
> On 2019-10-17 4:54 a.m., Christian König wrote:
>> Am 16.10.19 um 18:04 schrieb Jason Gunthorpe:
>>> On Wed, Oct 16, 2019 at 10:58:02AM +0200, Christian König wrote:
Am 15.10.19 um 20:12 schrieb Jason Gunthorpe:
>
Am 17.10.2019 18:26 schrieb "Yang, Philip" :
On 2019-10-17 4:54 a.m., Christian König wrote:
> Am 16.10.19 um 18:04 schrieb Jason Gunthorpe:
>> On Wed, Oct 16, 2019 at 10:58:02AM +0200, Christian König wrote:
>>> Am 15.10.19 um 20:12 schrieb Jason Gunthorpe:
From: Jason Gunthorpe
t?
thanks.
Best Regards,
Kevin
________
From: Koenig, Christian
<mailto:christian.koe...@amd.com>
Sent: Wednesday, October 16, 2019 8:15 PM
To: Wang, Kevin(Yang) <mailto:kevin1.w...@amd.com>;
amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org>
<mailto:amd-gfx@lists.f
Hi Kevin,
well that copies the string into the ring buffer every time the trace event is
called which is not necessary a good idea for a constant string.
Can't we avoid that somehow?
Thanks,
Christian.
Am 16.10.19 um 14:01 schrieb Wang, Kevin(Yang):
add @Koenig, Christian<mailto:christian.
Am 14.10.19 um 15:01 schrieb Alex Deucher:
> On Mon, Oct 14, 2019 at 5:06 AM Christian König
> wrote:
>> Am 11.10.19 um 22:50 schrieb Alex Deucher:
>>> We need to allocate a large enough buffer for the
>>> session info, otherwise the IB test can overwrite
>>> other memory.
>>>
>>> Bug:
Am 12.10.19 um 01:23 schrieb Tuikov, Luben:
> On 2019-10-10 11:50 p.m., Tianci Yin wrote:
>> From: "Tianci.Yin"
>>
>> memory training using specific fixed vram segment, reserve these
>> segments before anyone may allocate it.
>>
>> Change-Id: I1436755813a565608a2857a683f535377620a637
>>
Forwarding to the appropriate display folks.
Can you guys take a look?
Christian.
Am 11.10.19 um 01:34 schrieb Gabriel C:
> Hello,
>
> I've built recently a new box with a Ryzen3 2200G APU.
>
> Each time I plug in an HDMI cable ( to a TV or Monitor ),
> or boot with HDMI connected a lot
Am 10.10.19 um 16:34 schrieb Alex Deucher:
> AOn Thu, Oct 10, 2019 at 5:54 AM Daniel Vetter wrote:
>> On Thu, Oct 10, 2019 at 6:17 AM Alex Deucher wrote:
>>> [SNIP]
>>> Christian König (22):
>>>drm/amdgpu: use moving fence instead of exclusive for VM updates
>>>drm/amdgpu:
Am 10.10.19 um 12:42 schrieb Nirmoy Das:
> amdgpu_vm_handle_fault should return true on success
NAK, that is intentional.
There is a follow up patch which didn't made it into our server branch
which implements faults handling.
We could actually change the return value to void until that one
Hi Yizhuo,
Am 10.10.19 um 07:09 schrieb Yizhuo Zhai:
> Hi All:
> drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c:
> The function to_amdgpu_fence() could return NULL, but callers
> in this file does not check the return value but directly dereference it,
> which seems potentially unsafe.
> Such callers
Hi Philip,
Am 04.10.19 um 15:40 schrieb Yang, Philip:
> Thanks Joe for the test, I will add your Tested-by.
>
> Hi Christian,
>
> May you help review? The change removes the get user pages from
> gem_userptr_ioctl, this was done if flags AMDGPU_GEM_USERPTR_VALIDATE is
> set, and delay the get
Am 04.10.19 um 15:51 schrieb Nirmoy Das:
> cleanup error handling code and make sure temporary info array
> with the handles are freed by amdgpu_bo_list_put() on
> idr_replace()'s failure.
>
> Signed-off-by: Nirmoy Das
Reviewed-by: Christian König
> ---
>
Am 03.10.19 um 23:40 schrieb Colin King:
> From: Colin Ian King
>
> There is a return statement that is not reachable and a variable that
> is not used. Remove them.
>
> Addresses-Coverity: ("Structurally dead code")
> Fixes: de7b45babd9b ("drm/amdgpu: cleanup creating BOs at fixed location
>
Am 03.10.19 um 23:52 schrieb Colin King:
> From: Colin Ian King
>
> The boolean variable pasid_mapping_needed is not initialized and
> there are code paths that do not assign it any value before it is
> is read later. Fix this by initializing pasid_mapping_needed to
> false.
>
>
Am 03.10.19 um 22:18 schrieb Davidlohr Bueso:
> The amdgpu_vm interval tree really wants [a, b) intervals,
NAK, we explicitly do need an [a, b[ interval here.
Regards,
Christian.
> not fully closed ones. As such convert it to use the new
> interval_tree_gen.h, and also rename the 'last'
Am 03.10.2019 10:25 schrieb "Pelloux-prayer, Pierre-eric"
:
On 03/10/2019 10:09, Christian König wrote:
> Am 03.10.19 um 10:03 schrieb Pelloux-prayer, Pierre-eric:
>> This can be safely skipped entirely.
>> This seems to help with https://bugs.freedesktop.org/show_bug.cgi?id=111481.
>
> NAK,
Am 02.10.19 um 05:46 schrieb Navid Emamdoost:
> In acp_hw_init there are some allocations that needs to be released in
> case of failure:
>
> 1- adev->acp.acp_genpd should be released if any allocation attemp for
> adev->acp.acp_cell, adev->acp.acp_res or i2s_pdata fails.
> 2- all of those
Am 30.09.19 um 23:26 schrieb Navid Emamdoost:
> In acp_hw_init there are some allocations that needs to be released in
> case of failure:
>
> 1- adev->acp.acp_genpd should be released if any allocation attemp for
> adev->acp.acp_cell, adev->acp.acp_res or i2s_pdata fails.
> 2- all of those
parts. so maybe the patch
is fine as is.
Alex
____
From: Koenig, Christian
Sent: Thursday, September 26, 2019 2:02 PM
To: Yuan, Xiaojie
Cc: Alex Deucher ; Deucher, Alexander
; amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amdgpu/gmc10: apply the 'invalidation
:
Hi Alex / Christian,
When gfxoff is enabled for Navi12, I observed sdma0 hang while launching
desktop. When this workaround is applied, the issue fades away.
That's why I included this workaround for Navi12 as well.
BR,
Xiaojie
____
From: Koenig, Christian
Sent
Am 26.09.2019 15:51 schrieb Alex Deucher :
On Thu, Sep 26, 2019 at 9:47 AM Koenig, Christian
wrote:
>
> Am 26.09.19 um 15:40 schrieb Alex Deucher:
> > On Thu, Sep 26, 2019 at 8:29 AM Christian König
> > wrote:
> >> Stop, wait a second guys!
> >>
> >>
Am 25.09.19 um 16:54 schrieb Huang, Ray:
>> -Original Message-
>> From: Koenig, Christian
>> Sent: Wednesday, September 25, 2019 10:47 PM
>> To: Huang, Ray ; amd-gfx@lists.freedesktop.org; dri-
>> de...@lists.freedesktop.org; Deucher, Alexander
>>
Am 25.09.19 um 16:38 schrieb Huang, Ray:
> Mark a job as secure, if and only if the command
> submission flag has the secure flag set.
>
> v2: fix the null job pointer while in vmid 0
> submission.
> v3: Context --> Command submission.
> v4: filling cs parser with cs->in.flags
>
> Signed-off-by:
1 - 100 of 480 matches
Mail list logo
