From: Lee Jones
commit e79a2398e1b2d47060474dca291542368183bc0f upstream.
This ensures userspace cannot prematurely clean-up the client before
it is fully initialised which has been proven to cause issues in the
past.
Cc: Felix Kuehling
Cc: Alex Deucher
Cc: "Christian König"
Cc: "Pan, Xinhui
From: Lee Jones
commit e79a2398e1b2d47060474dca291542368183bc0f upstream.
This ensures userspace cannot prematurely clean-up the client before
it is fully initialised which has been proven to cause issues in the
past.
Cc: Felix Kuehling
Cc: Alex Deucher
Cc: "Christian König"
Cc: "Pan, Xinhui
From: Lee Jones
commit e79a2398e1b2d47060474dca291542368183bc0f upstream.
This ensures userspace cannot prematurely clean-up the client before
it is fully initialised which has been proven to cause issues in the
past.
Cc: Felix Kuehling
Cc: Alex Deucher
Cc: "Christian König"
Cc: "Pan, Xinhui
> On Apr 12, 2022, at 8:07 AM, Felix Kuehling wrote:
>
> Am 2022-04-08 um 04:45 schrieb Shuotao Xu:
>> Currently, the IO-links to the device being removed from topology,
>> are not cleared. As a result, there would be dangling links left in
>> the KFD topology. This patch aims to fix the follow
VM might already be freed when amdgpu_vm_tlb_seq_cb() is called. We see
the calltrace below.
Fix it by adding vm.delayed_tlb_flush and check this value in vm_fini().
BUG kmalloc-4k (Not tainted): Poison overwritten
0x9c88630414e8-0x9c88630414e8 @offset=5352. First byte 0x6c
instead of 0
[AMD Official Use Only]
Thanks Lijo.
Got it.
-Original Message-
From: Lazar, Lijo
Sent: Tuesday, 12 April 2022 11:03 am
To: Zhang, Jesse(Jie) ; Paul Menzel
Cc: Deucher, Alexander ; Zhang, Yifan
; Huang, Ray ;
amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH ] drm/amdgpu: fix discove
[Cc: +x86 folks]
Dear Alex, dear x86 folks,
x86 folks, can you think of alternatives to access `X86_HYPER_MS_HYPERV`
from `arch/x86/include/asm/hypervisor.h` without any preprocessor ifdef-ery?
Am 11.04.22 um 18:28 schrieb Alex Deucher:
On Mon, Apr 11, 2022 at 11:28 AM Paul Menzel wrote:
Dear Jie,
Am 12.04.22 um 03:52 schrieb Zhang, Jesse (Jie):
[AMD Official Use Only]
Thanks Paul Menzel
Attach the patch file .
Please do not attach patch files, as it breaks work flows and inline
commenting. Please use `git send-email` or equivalent. Your colleagues
should be able to help
On Mon, 11 Apr 2022 at 19:51, Arunpravin Paneer Selvam
wrote:
>
> Add a set of drm buddy test cases to validate the
> drm/drm_buddy.c memory allocator.
>
> v2: sorted in alphabetical order
>
> Signed-off-by: Arunpravin Paneer Selvam
> Reviewed-by: Matthew Auld
Tests look to be passing in CI sha
Dear Cal,
Am 12.04.22 um 00:31 schrieb Cal Peake:
I wanted to put a capper on this just in case anyone was interested, or in
case any future people find this thread, because I did find a resolution.
Yes, that is very much appreciated.
Turns out the way to stop the system from crashing was
Am 12.04.22 um 09:16 schrieb xinhui pan:
VM might already be freed when amdgpu_vm_tlb_seq_cb() is called. We see
the calltrace below.
Fix it by adding vm.delayed_tlb_flush and check this value in vm_fini().
BUG kmalloc-4k (Not tainted): Poison overwritten
Shit, I feared that this could happe
The series is Reviewed-by: Stanley.Yang
Regards,
Stanley
> -邮件原件-
> 发件人: Zhou1, Tao
> 发送时间: Tuesday, April 12, 2022 11:06 AM
> 收件人: Yang, Stanley ; amd-
> g...@lists.freedesktop.org; Lazar, Lijo ; Ziya,
> Mohammad zafar ; Zhang, Hawking
> ; Chai, Thomas
> 主题: RE: [PATCH 1/3] drm/amdgpu:
VM might already be freed when amdgpu_vm_tlb_seq_cb() is called.
We see the calltrace below.
Fix it by keeping the last flush fence around and wait for it to signal
BUG kmalloc-4k (Not tainted): Poison overwritten
0x9c88630414e8-0x9c88630414e8 @offset=5352. First byte 0x6c
instead of 0x6
Am 12.04.22 um 14:03 schrieb xinhui pan:
VM might already be freed when amdgpu_vm_tlb_seq_cb() is called.
We see the calltrace below.
Fix it by keeping the last flush fence around and wait for it to signal
BUG kmalloc-4k (Not tainted): Poison overwritten
0x9c88630414e8-0x9c88630414e8 @
On Tue, Apr 12, 2022 at 08:52:11AM +0200, Paul Menzel wrote:
> > Reviewed-by: George Shen
> > Acked-by: Alex Hung
> > Signed-off-by: Martin Leung
>
> Shouldn’t the Signed-off-by line by the author go first?
No, this is the correct order.
thanks,
greg k-h
From: Lee Jones
commit e79a2398e1b2d47060474dca291542368183bc0f upstream.
This ensures userspace cannot prematurely clean-up the client before
it is fully initialised which has been proven to cause issues in the
past.
Cc: Felix Kuehling
Cc: Alex Deucher
Cc: "Christian König"
Cc: "Pan, Xinhui
MS_HYPERV with vega10 doesn't have the interface to process
request init data msg.
Check hypervisor type to not send the request for MS_HYPERV.
Signed-off-by: Yongqiang Sun
---
drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --g
[AMD Official Use Only]
-Original Message-
From: Sun, Yongqiang
Sent: April 12, 2022 9:16 AM
To: amd-gfx@lists.freedesktop.org; Wong, Alice
Cc: Yao, Yiqing(James) ; Sun, Yongqiang
Subject: [PATCH] drm/amd/amdgpu: Not request init data for MS_HYPERV with vega10
MS_HYPERV with vega10
On Tue, Apr 12, 2022 at 4:01 AM Paul Menzel wrote:
>
> [Cc: +x86 folks]
>
> Dear Alex, dear x86 folks,
>
>
> x86 folks, can you think of alternatives to access `X86_HYPER_MS_HYPERV`
> from `arch/x86/include/asm/hypervisor.h` without any preprocessor ifdef-ery?
I don't really see what problem that
Active State Power Management (ASPM) feature is enabled since kernel 5.14.
There are some AMD GFX cards (such as WX3200 and RX640) that won't work
with ASPM-enabled Intel Alder Lake based systems. Using these GFX cards as
video/display output, Intel Alder Lake based systems will hang during
suspend
On Tue, Apr 12, 2022 at 2:52 AM Paul Menzel wrote:
>
> [Cc: +dri-de...@lists.freedesktop.org, +Daniel Vetter, +Alexander
> Deucher, +Greg KH]
>
>
> Dear Alex,
>
>
> I am a little confused and upset about how Display Core patches are
> handled in the Linux kernel.
>
>
> Am 25.03.22 um 23:53 schrieb
[ Upstream commit b40a6ab2cf9213923bf8e821ce7fa7f6a0a26990 ]
This is a partial cherry-pick of the above upstream commit.
It ensures the file descriptor passed in by userspace is a valid one.
Cc: Felix Kuehling
Cc: Alex Deucher
Cc: "Christian König"
Cc: David Airlie
Cc: Daniel Vetter
Cc: amd
From: Bas Nieuwenhuizen
[ Upstream commit 021830d24ba55a578f602979274965344c8e6284 ]
Otherwise we interpret the file private data as drm & amdgpu data
while it might not be, possibly allowing one to get memory corruption.
Cc: Felix Kuehling
Cc: Alex Deucher
Cc: "Christian König"
Cc: David Ai
[ Upstream commit b40a6ab2cf9213923bf8e821ce7fa7f6a0a26990 ]
This is a partial cherry-pick of the above upstream commit.
It ensures the file descriptor passed in by userspace is a valid one.
Cc: Felix Kuehling
Cc: Alex Deucher
Cc: "Christian König"
Cc: David Airlie
Cc: Daniel Vetter
Cc: amd
On Tue, Apr 12, 2022 at 10:59 AM Richard Gong wrote:
>
> Active State Power Management (ASPM) feature is enabled since kernel 5.14.
> There are some AMD GFX cards (such as WX3200 and RX640) that won't work
> with ASPM-enabled Intel Alder Lake based systems. Using these GFX cards as
> video/display
- Add proper indentation in the header file
- In the latest version of the header, there is a variable name change.
This should not cause any backward compatibility since the variable is
at the same offset in the struct.
Signed-off-by: Bokun Zhang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device
On Tue, Apr 12, 2022 at 12:04 PM Bokun Zhang wrote:
>
> - Add proper indentation in the header file
> - In the latest version of the header, there is a variable name change.
> This should not cause any backward compatibility since the variable is
> at the same offset in the struct.
Please spl
This reverts commit 367b3e934f578f6c0d5d8ca5987dc6ac4cd6831d.
While we were testing DCN3.1 with a hub, we noticed that only one of 2
connected displays lights up when using some specific display
resolution. After bisecting this issue, we figured out the commit
mentioned above introduced this issue
Dear Rodrigo,
Thank you for the patch.
Am 12.04.22 um 20:44 schrieb Rodrigo Siqueira:
This reverts commit 367b3e934f578f6c0d5d8ca5987dc6ac4cd6831d.
While we were testing DCN3.1 with a hub, we noticed that only one of 2
connected displays lights up when using some specific display
resolution.
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: d0c745e7b2d6ce8bcc768b32361ab8ef520821ee Add linux-next specific
files for 20220412
Error/Warning reports:
https://lore.kernel.org/linux-mm/202203160358.yulpl6b4-...@intel.com
https
This reverts commit 367b3e934f578f6c0d5d8ca5987dc6ac4cd6831d.
While we were testing DCN3.1 with a hub, we noticed that only one of 2
connected displays lights up when using some specific display
resolution. In summary, this was the setup:
1. Displays:
* Sharp LQ156M1JW26 (eDP): 1080@240
* BENQ
I suppose I didn't quite register this on a first read:
On 2022-04-12 00:08, Darren Powell wrote:
> Contrary to the smu_cmn_send_smc_msg_with_param documentation, two
I'd just say
Clarify the documentation to also mention that we drop
messages and return success in the following two cases:
- Add proper indentation in the header file
Signed-off-by: Bokun Zhang
---
drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h | 95 ++---
1 file changed, 46 insertions(+), 49 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h
b/drivers/gpu/drm/amd/amdgpu/amdgv_sriov
- In the latest version of the header, there is a variable name change.
This should not cause any backward compatibility since the variable is
at the same offset in the struct.
Signed-off-by: Bokun Zhang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgv
[AMD Official Use Only]
Ack. I will submit them separately in different patches.
Thanks!
-Original Message-
From: Alex Deucher
Sent: Tuesday, April 12, 2022 1:30 PM
To: Zhang, Bokun
Cc: amd-gfx list
Subject: Re: [PATCH] drm/amd/amdgpu: Update PF2VF header
On Tue, Apr 12, 2022 at 12:
Active State Power Management (ASPM) feature is enabled since kernel 5.14.
There are some AMD GFX cards (such as WX3200 and RX640) that won't work
with ASPM-enabled Intel Alder Lake based systems. Using these GFX cards as
video/display output, Intel Alder Lake based systems will hang during
suspend
Add the waiters to the wait queue during initialization, while holding the
event spinlock. Otherwise the waiter will not get activated if the event
signals before being added to the wait queue.
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdkfd/kfd_events.c | 26 +--
On Tue, 12 Apr 2022 at 07:13, Paul Menzel wrote:
> Am 11.04.22 um 23:39 schrieb James Dutton:
> So, did you do any changes to Linux? Why do you think the EDID is at fault?
>
> […]
>
> I suggest to analyze, why `No DP link bandwidth` is logged. The macro is
> `DC_NO_DP_LINK_BANDWIDTH`, and you shou
[AMD Official Use Only]
I needed to dig further down to find the message map, I had been looking back
in mailing list looking for clarification but hadn't found anything.
Will reword
Thanks
Darren
From: Lazar, Lijo
Sent: Tuesday, April 12, 2022 12:19 AM
To: Powel
[AMD Official Use Only]
Yes, it looks like I was a little snippy writing that intro, will lighten the
grammar.
Thanks
Darren
From: Tuikov, Luben
Sent: Tuesday, April 12, 2022 5:09 PM
To: Powell, Darren ; amd-gfx@lists.freedesktop.org
Cc: Quan, Evan ; pmen...@mo
[AMD Official Use Only]
we make something like dma_fence_release does.
@@ -783,11 +783,15 @@ dma_fence_default_wait(struct dma_fence *fence, bool
intr, signed long timeout)
unsigned long flags;
signed long ret = timeout ? timeout : 1;
- if (test_bit(DMA_FENCE_FLAG_SIGNALED
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
still see lru_list not empty warnging.
Fix it by waiting all BO to be destroyed.
Signed-off-by: xinhui pan
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.
On 4/13/2022 3:20 AM, Richard Gong wrote:
Active State Power Management (ASPM) feature is enabled since kernel 5.14.
There are some AMD GFX cards (such as WX3200 and RX640) that won't work
with ASPM-enabled Intel Alder Lake based systems. Using these GFX cards as
video/display output, Intel Al
Clarify the smu_cmn_send_smc_msg_with_param documentation to mention two
cases exist where messages are silently dropped with no error returned.
These cases occur in unusual situations where either:
1. the message type is not allowed to a virtual GPU, or
2. a PCI recovery is underway and the HW i
+ msleep((HZ / 100) < 1) ? 1 : HZ / 100);
a "(" is missed. With it fixed, this patch is:
Acked-by: Guchun Chen
Regards,
Guchun
-Original Message-
From: amd-gfx On Behalf Of xinhui pan
Sent: Wednesday, April 13, 2022 11:09 AM
To: amd-gfx@lists.freedesktop.org
Cc: D
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
still see lru_list not empty warnging.
Fix it by waiting all BO to be destroyed.
Acked-by: Guchun Chen
Signed-off-by: xinhui pan
---
drivers/gpu/drm/am
46 matches
Mail list logo