[AMD Public Use]
Please put the check __is_ras_eeprom_supported behind the line
'*exceed_err_limit = false;' in function amdgpu_ras_eeprom_init and
amdgpu_ras_eeprom_check_err_threshold respectively. That promises, even when
eeprom is not available on several ASICs, exceed_err_limit must set to
Hi, Andy,
On Fri, Jul 31, 2020 at 04:34:11PM -0700, Andy Lutomirski wrote:
> On Mon, Jul 13, 2020 at 4:48 PM Fenghua Yu wrote:
> >
> > A #GP fault is generated when ENQCMD instruction is executed without
> > a valid PASID value programmed in the current thread's PASID MSR. The
> > #GP fault handl
Hey Matt,
I have just tested the amd-staging-drm-next branch
(dd654c76d6e854afad716ded899e4404734aaa10) with my patches reverted
and I can reproduce your issue with:
sudo sh -c 'echo "s 0 305 750" >
/sys/class/drm/card0/device/pp_od_clk_voltage'
Which makes the sh hang with 100% usage.
The
On an error exit path, a negative error code should be returned
instead of a positive return value.
Fixes: 9e869063b0021 ("drm/amd/display: Move iteration out of dm_update_planes")
Cc: Leo Li
Signed-off-by: Tianjia Zhang
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 +--
1 file chan
On Thu, Jul 30, 2020 at 11:09 PM Luben Tuikov wrote:
> On 2020-07-29 9:49 a.m., Alex Deucher wrote:
> > On Wed, Jul 29, 2020 at 4:11 AM Christian König
> > wrote:
> >>
> >> Am 28.07.20 um 21:29 schrieb Peilin Ye:
> >>> Compiler leaves a 4-byte hole near the end of `dev_info`, causing
> >>> amdgpu
Hello again,
I just finished a bisect of amd-staging-drm-next and it looks like
the hang is first introduced in edad8312cbbf9a33c86873fc4093664f150dd5c1
("drm/amdgpu: fix system hang issue during GPU reset").
It is a bit tricky, because it is commited on top of my first faulty patch
7173949df4548
The if statement wasn't indented so it's confusing.
Signed-off-by: Dan Carpenter
---
drivers/gpu/drm/amd/display/dc/core/dc_resource.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
b/drivers/gpu/drm/amd/display/dc/core/dc_r
On Mon, Aug 3, 2020 at 8:03 AM Dave Hansen wrote:
>
> On 7/31/20 4:34 PM, Andy Lutomirski wrote:
> >> Thomas suggested to provide a reason for the #GP caused by executing ENQCMD
> >> without a valid PASID value programmed. #GP error codes are 16 bits and all
> >> 16 bits are taken. Refer to SDM Vo
Thanks Evan! I can confirm that this resolved the following GitLab
issue. Thanks for CC'ing me!
https://gitlab.freedesktop.org/drm/amd/-/issues/1243
Series is Tested-by: Matt Coffin
On 8/2/20 10:46 PM, Evan Quan wrote:
> As VCN related dpm table setup needs VCN be in PG ungate state. Same logic
Hi Evan,
Thanks for the work. It would have taken me probably forever to find that.
I replied to your series with a Tested-by, and I tested locally. With
edad8312cbbf9a33c86873fc4093664f150dd5c1 reverted to fix the sysfs
interfaces, and your series, I once again have a 100% working OD system!
Th
On Mon, Aug 3, 2020 at 9:37 AM Dave Hansen wrote:
>
> On 8/3/20 8:12 AM, Andy Lutomirski wrote:
> > I could easily be convinced that the PASID fixup is so trivial and so
> > obviously free of misfiring in a way that causes an infinite loop that
> > this code is fine. But I think we first need to
On 7/31/20 4:34 PM, Andy Lutomirski wrote:
>> Thomas suggested to provide a reason for the #GP caused by executing ENQCMD
>> without a valid PASID value programmed. #GP error codes are 16 bits and all
>> 16 bits are taken. Refer to SDM Vol 3, Chapter 16.13 for details. The other
>> choice was to re
On 8/3/20 10:16 AM, Andy Lutomirski wrote:
> - TILE: genuinely per-thread, but it's expensive so it's
> lazy-loadable. But the lazy-load mechanism reuses #NM, and it's not
> fully disambiguated from the other use of #NM. So it sort of works,
> but it's gross.
For those playing along at home, the
Hi, Andy,
On Fri, Jul 31, 2020 at 06:28:37PM -0700, Andy Lutomirski wrote:
> On Mon, Jul 13, 2020 at 4:48 PM Fenghua Yu wrote:
> >
> > A #GP fault is generated when ENQCMD instruction is executed without
> > a valid PASID value programmed in the current thread's PASID MSR. The
> > #GP fault handl
On 8/3/20 8:12 AM, Andy Lutomirski wrote:
> I could easily be convinced that the PASID fixup is so trivial and so
> obviously free of misfiring in a way that causes an infinite loop that
> this code is fine. But I think we first need to answer the bigger
> question of why we're doing a lazy fixup
On Mon, Aug 03, 2020 at 08:12:18AM -0700, Andy Lutomirski wrote:
> On Mon, Aug 3, 2020 at 8:03 AM Dave Hansen wrote:
> >
> > On 7/31/20 4:34 PM, Andy Lutomirski wrote:
> > >> Thomas suggested to provide a reason for the #GP caused by executing
> > >> ENQCMD
> > >> without a valid PASID value prog
[Why]
Under DP daisy chain scenario as below:
Src - Monitor_1 - Monitor_2
If unplug 2nd Monitor_2 and plug in again, observe that Monitor_1
doesn't light up.
When unplug 2nd monitor, we clear the
dc_link->cur_link_settings.lane_count in dm_dp_destroy_mst_connector().
However this link st
[Why]
Under DP daisy chain scenario as below:
Src - Monitor_1 - Monitor_2
If unplug 2nd Monitor_2 and plug in again, observe that Monitor_1
doesn't light up.
When unplug 2nd monitor, we clear the
dc_link->cur_link_settings.lane_count in dm_dp_destroy_mst_connector().
However this link st
[Why]
According to DP spec, DPRX with DPCD r1.2 or higher shall have the
same Link/Sink Device Status field registers at DPCD Addresses 00200h
through 00205h to the corresponding DPRX Event Status Indicator
registers at DPCD Addresses 02002h through 0200Fh. We now only read from
02002h when DPCD re
[AMD Public Use]
Sorry for spamming.
It's a duplicate one and should be ignored.
> -Original Message-
> From: Wayne Lin
> Sent: Tuesday, August 4, 2020 11:37 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Pillai, Aurabindo ; Wu, Hersen
> ; Kazlauskas, Nicholas
> ; Siqueira, Rodrigo
> ; Zu
[AMD Official Use Only - Internal Distribution Only]
Ping ... this is a severe bug fix
_
Monk Liu|GPU Virtualization Team |AMD
-Original Message-
From: amd-gfx On Behalf Of Liu, Monk
Sent: Monday, August 3, 2020 9:55 AM
To: Kuehling, Felix ; amd-gfx@
21 matches
Mail list logo
