The patch is enabling mode-1 reset for RAS recovery in fatal error mode.
Signed-off-by: YiPeng Chai
Reviewed-by: Hawking Zhang
Reviewed-by: Tao Zhou
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c| 7 ++-
2 files changed, 10
[AMD Official Use Only - General]
> -Original Message-
> From: amd-gfx On Behalf Of
> Jonatas Esteves
> Sent: Tuesday, November 15, 2022 7:13 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Jonatas Esteves
> Subject: [PATCH] drm/amd/pm: Fix output of pp_od_clk_voltage
>
> Printing the
Printing the other clock types should not be conditioned on being able
to print OD_SCLK. Some GPUs currently have limited capability of only
printing a subset of these.
Since this condition was introduced in v5.18-rc1, reading from
`pp_od_clk_voltage` has been returning empty on the Asus ROG
There's been a very long running bug that seems to have been neglected for
a while, where amdgpu consistently triggers a KASAN error at start:
BUG: KASAN: global-out-of-bounds in read_indirect_azalia_reg+0x1d4/0x2a0
[amdgpu]
Read of size 4 at addr c2274b28 by task modprobe/1889
Looks like that we're accidentally dropping a pretty important return code
here. For some reason, we just return -EINVAL if we fail to get the MST
topology state. This is wrong: error codes are important and should never
be squashed without being handled, which here seems to have the potential
to
Now that we've fixed the issue with using the incorrect topology manager,
we're actually grabbing the topology manager's lock - and consequently
deadlocking. Luckily for us though, there's actually nothing in AMD's DSC
state computation code that really should need this lock. The one exception
is
This bug hurt me. Basically, it appears that we've been grabbing the
entirely wrong mutex in the MST DSC computation code for amdgpu! While
we've been grabbing:
amdgpu_dm_connector->mst_mgr
That's zero-initialized memory, because the only connectors we'll ever
actually be doing DSC
It appears that amdgpu makes the mistake of completely ignoring the return
values from the DP MST helpers, and instead just returns a simple
true/false. In this case, it seems to have come back to bite us because as
a result of simply returning false from
compute_mst_dsc_configs_for_state(),
There was a bit of unexpected fallout from the atomic-only conversion
patches that I had pushed a while ago, which mostly affected amdgpu.
This fixes most of the severe issues, although we're still investigating
some lingering issues (which I suspect may just fix themselves following
this
On Wed, 2022-11-09 at 09:48 +, Lin, Wayne wrote:
> > }
> > - if (!drm_dp_mst_atomic_check(state) && !debugfs_overwrite) {
> > + ret = drm_dp_mst_atomic_check(state);
> > + if (ret == 0 && !debugfs_overwrite) {
> > set_dsc_configs_from_fairness_vars(params, vars, count,
>
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 5c92ddca1053df02387e8006d06094e18cc8538a Add linux-next specific
files for 20221114
Error/Warning reports:
https://lore.kernel.org/oe-kbuild-all/202211041320.coq8eelj-...@intel.com
https
On Wed, 2022-11-09 at 09:48 +, Lin, Wayne wrote:
> [Public]
>
> Thanks, Lyude!
> Comments inline.
>
> > -Original Message-
> > From: Lyude Paul
> > Sent: Saturday, November 5, 2022 7:59 AM
> > To: amd-gfx@lists.freedesktop.org
> > Cc: Wentland, Harry ; sta...@vger.kernel.org;
> >
[Public]
Conceptually makes sense to me, but please see below comments:
> -Original Message-
> From: roman...@amd.com
> Sent: Monday, November 14, 2022 15:07
> To: amd-gfx@lists.freedesktop.org; Deucher, Alexander
> ; Wentland, Harry
> ; Limonciello, Mario
> ; Rizvi, Saaem
> Cc: Li,
From: Roman Li
[Why]
Assert on non-OK response from SMU is unnecessary.
It was replaced with respective log message on other asics
in the past with commit:
"drm/amd/display: Removing assert statements for Linux"
[How]
Remove asert and add dbg logging as on other DCNs.
CC: Saaem Rizvi
On 11/14/2022 12:45, Eric Huang wrote:
It is to resolve a regression, which fails to allocate
VRAM due to no free memory in application, the reason
is we add check of vram_pin_size for memory limit, and
application is pinning the memory for Peerdirect, KFD
should not count it in memory limit. So
Am 2022-11-14 um 13:45 schrieb Eric Huang:
It is to resolve a regression, which fails to allocate
VRAM due to no free memory in application, the reason
is we add check of vram_pin_size for memory limit, and
application is pinning the memory for Peerdirect, KFD
should not count it in memory
It is to resolve a regression, which fails to allocate
VRAM due to no free memory in application, the reason
is we add check of vram_pin_size for memory limit, and
application is pinning the memory for Peerdirect, KFD
should not count it in memory limit. So removing
vram_pin_size will resolve it.
On 2022-11-10 18:00, Michel Dänzer wrote:
> On 2022-11-08 09:01, Zhu, Jiadong wrote:
>>
>> I reproduced the glxgears 400fps scenario locally. The issue is caused by
>> the patch5 "drm/amdgpu: Improve the software rings priority scheduler" which
>> slows down the low priority scheduler thread if
Hi, this is your Linux kernel regression tracker. Top-posting for once,
to make this easily accessible to everyone.
Christian, was any progress made to address this? It looks stalled sine
10+ days, as I looked for posts and commits that referenced this report,
but couldn't find anything.
Ciao,
Hi Mikhail,
Am 02.11.22 um 14:43 schrieb Christian König:
Am 02.11.22 um 14:36 schrieb Mikhail Gavrilov:
On Tue, Nov 1, 2022 at 10:52 PM Christian König
wrote:
[SNIP]
But the most interesting thing is that all previous kernels 6.0, 5.19
are affected by the problem. It is not enough to revert
On Fri, Nov 11, 2022 at 03:17:09PM -0700, Jim Cromie wrote:
> drm.debug-on-dyndbg has a regression, due to a chicken-egg
> initialization problem:
>
> 1- modprobe i915
>i915 needs drm.ko, which is loaded 1st
>
> 2- "modprobe drm drm.debug=0x1ff" (virtual/implied)
>drm.debug is set
Am 13.11.22 um 13:42 schrieb Dawei Li:
Both find_vma() and get_user_pages() need explicit protection of
mmap lock, fix them by mmap_lock and get_user_pages_fast().
NAK, the MM read lock should already be taken when we reach this function.
Could be that this is buggy and the function is called
Both find_vma() and get_user_pages() need explicit protection of
mmap lock, fix them by mmap_lock and get_user_pages_fast().
Fixes: ddd00e33e17a ("drm/radeon: add userptr flag to limit it to anonymous
memory v2")
Fixes: f72a113a71ab ("drm/radeon: add userptr support v8")
Signed-off-by: Dawei Li
On Tue, Nov 01, 2022 at 12:06:55PM -0400, Alex Deucher wrote:
> On Tue, Nov 1, 2022 at 11:42 AM Filip Moc wrote:
> >
> > Hello Alex,
> >
> > thank you for your response.
> >
> > Yes, I have HP ENVY x360 Convertible 13-ay1xxx, and backlight_min=2
> > seems to work the best in my case.
> >
> > I
One-element arrays are deprecated, and we are replacing them with
flexible array members instead. So, replace one-element array with
flexible-array member in structs ATOM_I2C_VOLTAGE_OBJECT_V3,
ATOM_ASIC_INTERNAL_SS_INFO_V2, ATOM_ASIC_INTERNAL_SS_INFO_V3,
and refactor the rest of the code
adev->dm.dc is already checked in a few other if branches of the same
function so no reason not to check it everywhere else as well.
Moreover, admgpu_dm_fini() can be called from an error branch in
amdgpu_dm_init(), at which point it won't contain a valid dm.dc.
This might happen, for example,
26 matches
Mail list logo
