Patch https://patchwork.freedesktop.org/series/106024/ should fix this.
Regards,
Guchun
-Original Message-
From: amd-gfx On Behalf Of Mikhail
Gavrilov
Sent: Tuesday, July 19, 2022 7:50 AM
To: amd-gfx list ; Linux List Kernel Mailing
; Christian König
Subject: Command "clinfo" causes
From: "Jiadong.Zhu"
Set register to enable mcbp according to amdgpu_mcbp.
Add sdma preempt_ib function used for debugfs test.
---
drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c | 53 ++
1 file changed, 53 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c
From: "Jiadong.Zhu"
1. Use unmap_queue package to trigger preemption on gfx9
Add trailing fence to track the preemption done.
2. Modify emit_ce_meta emit_de_meta functions
for the resumed ibs.
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h | 1 +
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c|
ping.
On 07/14/ , Lang Yu wrote:
> The driver can only support AMDGPU_MAX_GFX_RINGS gfx queues
> at the moment. Once enabled gfx queues exceed the limit,
> we will run into problems when setting up gfx rings in
> gfx_xxx_sw_init().
>
> Signed-off-by: Lang Yu
> ---
>
On Wed, Jul 13, 2022 at 5:38 PM Mikhail Gavrilov
wrote:
> # first bad commit: [9cbbd694a58bdf24def2462276514c90cab7cf80] Merge
> drm/drm-next into drm-misc-next
>
Don't know who to thank but the issue disappeared in 5.19 rc7.
--
Best Regards,
Mike Gavrilov.
Hi guys I continue testing 5.19 rc7 and found the bug.
Command "clinfo" causes BUG: kernel NULL pointer dereference, address:
0008 on driver amdgpu.
Here is trace:
[ 1320.203332] BUG: kernel NULL pointer dereference, address: 0008
[ 1320.203338] #PF: supervisor read access
This simplifies existing coherence handling for Arcturus and Aldabaran
to account for !coherent && uncached scenarios.
Cc: Joseph Greathouse
Cc: Alex Deucher
Signed-off-by: Rajneesh Bhardwaj
---
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 53 +--
1 file changed, 26
On Thu, 14 Jul 2022 08:00:32 -0700, Christian König wrote:
>
> Am 14.07.22 um 15:33 schrieb Alex Deucher:
> > On Thu, Jul 14, 2022 at 9:09 AM Christian König
> > wrote:
> >> Hi Mauro,
> >>
> >> well the last time I checked drm-tip was clean.
> >>
> >> The revert is necessary because we had some
On Mon, 18 Jul 2022 12:56:29 +0200 David Hildenbrand wrote:
> > /*
> > * Try to move out any movable page before pinning the range.
> > */
> > @@ -1919,7 +1948,8 @@ static long check_and_migrate_movable_pages(unsigned
> > long nr_pages,
> >
Am 18.07.22 um 21:32 schrieb Gavin Wan:
The scratch register should be accessed through MMIO instead of RLCG
in SRIOV, since it being used in RLCG register access function.
Fixes: 0e1314781b9c("drm/amdgpu: nuke dynamic gfx scratch reg allocation")
Signed-off-by: Gavin Wan
Change-Id:
The scratch register should be accessed through MMIO instead of RLCG
in SRIOV, since it being used in RLCG register access function.
Fixes: 0e1314781b9c("drm/amdgpu: nuke dynamic gfx scratch reg allocation")
Signed-off-by: Gavin Wan
Change-Id: I888cb3b96856583e764b35a098bcf8bff01ad90c
---
Applied the series with some minor tweaks to the documentation.
Thanks!
Alex
On Thu, Jul 14, 2022 at 3:18 PM André Almeida wrote:
>
> Add a GFXOFF section at "GPU Power Controls" file, explaining what it is
> and how userspace can interact with it.
>
> Signed-off-by: André Almeida
> ---
>
Applied with a trivial fix for dcn314_resource.c.
Thanks!
Alex
On Sat, Jul 16, 2022 at 3:52 PM Melissa Wen wrote:
>
> Although dcn31_update_soc_for_wm_a() is only called in dml/dcn31/dcn31_fpu by
> dc->res_pool->funcs->update_soc_for_wm_a(dc, context), it's declared in
> dcn31_resource that is
Applied. Thanks!
On Thu, Jul 14, 2022 at 12:45 PM Maíra Canal wrote:
>
> On the dce_v6_0 and dce_v8_0 hpd tear down callback, the tmp variable
> should be written into the control register instead of 0.
>
> Fixes: b00861b9 ("drm/amd/amdgpu: port of DCE v6 to new headers (v3)")
> Fixes: 2285b91c
On Thu, Jul 14, 2022 at 12:46 PM Maíra Canal wrote:
>
> The parameters WritebackPixelFormat and WritebackVRatio are removed as
> they are not used on the function dml30_CalculateWriteBackDISPCLK.
Maybe this is done for consistency with other dml code for other DCN blocks?
Alex
>
>
Applied. Thanks!
Alex
On Thu, Jul 14, 2022 at 12:46 PM Maíra Canal wrote:
>
> Remove the variable MaxUsedBW from the function
> DISPCLKDPPCLKDCFCLKDeepSleepPrefetchParametersWatermarksAndPerformanceCalculation.
> As a side-effect, the variables MaxPerPlaneVActiveWRBandwidth and
> WRBandwidth
Applied. Thanks!
Alex
On Thu, Jul 14, 2022 at 12:46 PM Maíra Canal wrote:
>
> The variable regval from the function enc1_update_generic_info_packet
> and the variables dynamic_range_rgb and dynamic_range_ycbcr from the
> function enc1_stream_encoder_dp_set_stream_attribute are not currently
>
On Thu, Jul 14, 2022 at 12:46 PM Maíra Canal wrote:
>
> Remove the variable value0 from the function
> dcn10_link_encoder_update_mst_stream_allocation_table.
>
> This was pointed by clang with the following warning:
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_link_encoder.c:1223:11:
Applied. Thanks!
Alex
On Thu, Jul 14, 2022 at 12:46 PM Maíra Canal wrote:
>
> Remove the variables dispclk_delay_subtotal and dppclk_delay_subtotal from
> the function dml_rq_dlg_get_dlg_params.
>
> This was pointed by clang with the following warning:
>
>
Applied. Thanks!
Alex
On Thu, Jul 14, 2022 at 12:46 PM Maíra Canal wrote:
>
> Remove the unused unsigned int NumberOfStates from the file, which was
> declared but never hooked up.
>
> This was pointed by clang with the following warning:
>
>
Applied. Thanks!
Alex
On Thu, Jul 14, 2022 at 12:45 PM Maíra Canal wrote:
>
> Remove dml32_CalculatedoublePipeDPPCLKAndSCLThroughput function, which is not
> used in
> the codebase.
>
> This was pointed by clang with the following warning:
>
>
Applied. Thanks!
Alex
On Thu, Jul 14, 2022 at 12:45 PM Maíra Canal wrote:
>
> Remove the variable clk_src from the function dcn3_get_pix_clk_dividers.
>
> This was pointed by clang with the following warning:
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_clock_source.c:1279:25:
>
Applied. Thanks!
Alex
On Thu, Jul 14, 2022 at 12:45 PM Maíra Canal wrote:
>
> Turn previously global function into a static function as it is not used
> outside the file.
>
> Signed-off-by: Maíra Canal
> ---
> drivers/gpu/drm/amd/display/dc/dml/display_mode_vba.c | 2 +-
>
On 18.07.22 19:52, Felix Kuehling wrote:
> On 2022-07-18 06:50, David Hildenbrand wrote:
>> On 15.07.22 17:05, Alex Sierra wrote:
>>> [WHY]
>>> It makes more sense to have these helpers in zone specific header
>>> file, rather than the generic mm.h
>>>
>>> Signed-off-by: Alex Sierra
>> Acked-by:
On 2022-07-15 19:54, Alex Sierra wrote:
[WHY]
Unified memory with xnack off should be tracked, as userptr mappings
and legacy allocations do. To avoid oversuscribe system memory when
xnack off.
[How]
Exposing functions reserve_mem_limit and unreserve_mem_limit to SVM
API and call them on every
On 2022-07-18 06:50, David Hildenbrand wrote:
On 15.07.22 17:05, Alex Sierra wrote:
[WHY]
It makes more sense to have these helpers in zone specific header
file, rather than the generic mm.h
Signed-off-by: Alex Sierra
Acked-by: David Hildenbrand
Thank you! I don't think I have the
[Public]
Will do.
Alex
From: Kuehling, Felix
Sent: Monday, July 18, 2022 11:29 AM
To: Mike Lothian ; Christian König
Cc: Pan, Xinhui ; amd-gfx@lists.freedesktop.org
; Deucher, Alexander
; Koenig, Christian
Subject: Re: [PATCH] drm/amdgpu: Fix a NULL
Xinhui submitted this patch instead, which should address the same
issue: "drm/amdgpu: Remove one duplicated ef removal"
Alex, can you pick up that patch for drm-fixes for 5.19, if it's not too
late?
Thanks,
Felix
On 2022-07-18 10:58, Mike Lothian wrote:
Is this likely to land before
Is this likely to land before 5.19 final? It's been nearly 2 weeks
since I said if fixed an issue I was seeing
https://gitlab.freedesktop.org/drm/amd/-/issues/2074
On Fri, 8 Jul 2022 at 10:05, Christian König
wrote:
>
> Hi guys,
>
> well the practice to remove all fences by adding a NULL
Am 18.07.22 um 16:55 schrieb Ruijing Dong:
From VCN4, AMDGPU_HW_IP_VCN_ENC is re-used to support
both encoding and decoding jobs.
link: https://gitlab.freedesktop.org/mesa/drm/-/merge_requests/245/commits
Reviewed-by: Leo Liu
Signed-off-by: Ruijing Dong
Reviewed-by: Christian König
---
>From VCN4, AMDGPU_HW_IP_VCN_ENC is re-used to support
both encoding and decoding jobs.
link: https://gitlab.freedesktop.org/mesa/drm/-/merge_requests/245/commits
Reviewed-by: Leo Liu
Signed-off-by: Ruijing Dong
---
include/uapi/drm/amdgpu_drm.h | 4
1 file changed, 4 insertions(+)
diff
Am 15.07.22 um 07:20 schrieb Jason Wang:
The double `have' is duplicated in line 696, remove one.
The subject line is rather confusing since this isn't related to DMA-buf
at all.
Please change that to "drm/radeon:", apart from that the patch looks
good to me.
Christian.
Signed-off-by:
[AMD Official Use Only - General]
No, we don't plan to clone another one. I will modify the comment only and
remove the bias.
Thanks
Ruijing
-Original Message-
From: Koenig, Christian
Sent: Monday, July 18, 2022 10:37 AM
To: Dong, Ruijing ; Liu, Leo ;
amd-gfx@lists.freedesktop.org
Am 18.07.22 um 16:14 schrieb Dong, Ruijing:
[AMD Official Use Only - General]
What happened is that the encode ring was extended with decode functionality.
In other words we still use the same format for encoding, we just added another
one for decoding as well.
Just to clarify the format
[AMD Official Use Only - General]
>> What happened is that the encode ring was extended with decode
>> functionality. In other words we still use the same format for encoding, we
>> just added another one for decoding as well.
Just to clarify the format difference between legacy encoding and
Am 18.07.22 um 15:48 schrieb Leo Liu:
On 2022-07-18 02:57, Christian König wrote:
Am 15.07.22 um 22:04 schrieb Ruijing Dong:
From VCN4, AMDGPU_HW_IP_VCN_UNIFIED is used to support
both encoding and decoding jobs, it re-uses the same
queue number of AMDGPU_HW_IP_VCN_ENC.
link:
On 2022-07-18 02:57, Christian König wrote:
Am 15.07.22 um 22:04 schrieb Ruijing Dong:
From VCN4, AMDGPU_HW_IP_VCN_UNIFIED is used to support
both encoding and decoding jobs, it re-uses the same
queue number of AMDGPU_HW_IP_VCN_ENC.
link:
The double `have' is duplicated in line 696, remove one.
Signed-off-by: Jason Wang
---
drivers/gpu/drm/radeon/radeon_gem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/radeon_gem.c
b/drivers/gpu/drm/radeon/radeon_gem.c
index
[Public]
Hi all,
This week this patchset was tested on the following systems:
HP Envy 360, with Ryzen 5 4500U
Lenovo Thinkpad T14s Gen2, with AMD Ryzen 5 5650U
Sapphire Pulse RX5700XT
Reference AMD RX6800
Engineering board with Ryzen 9 5900H
These systems were tested on the following
On 15.07.22 17:05, Alex Sierra wrote:
> From: Alistair Popple
>
> Currently any attempts to pin a device coherent page will fail. This is
> because device coherent pages need to be managed by a device driver, and
> pinning them would prevent a driver from migrating them off the device.
>
>
On 15.07.22 17:05, Alex Sierra wrote:
> With DEVICE_COHERENT, we'll soon have vm_normal_pages() return
> device-managed anonymous pages that are not LRU pages. Although they
> behave like normal pages for purposes of mapping in CPU page, and for
> COW. They do not support LRU lists, NUMA migration
On 15.07.22 17:05, Alex Sierra wrote:
> [WHY]
> It makes more sense to have these helpers in zone specific header
> file, rather than the generic mm.h
>
> Signed-off-by: Alex Sierra
Acked-by: David Hildenbrand
--
Thanks,
David / dhildenb
Am 18.07.22 um 14:08 schrieb yehonsun:
The comments say that the product number is a 16-digit HEX string so the
buffer needs to be at least 17 characters to hold the NUL terminator.
The comments say that the product number is a 16-digit HEX string so the
buffer needs to be at least 17
The comments say that the product number is a 16-digit HEX string so the
buffer needs to be at least 17 characters to hold the NUL terminator.
The comments say that the product number is a 16-digit HEX string so the
buffer needs to be at least 17 characters to hold the NUL terminator.
On Fri, Jul 15, 2022 at 01:48:56PM +0530, Somalapuram, Amaranath wrote:
>
> On 7/14/2022 9:13 PM, André Almeida wrote:
> > Às 12:06 de 14/07/22, Sebin Sebastian escreveu:
> > > On Tue, Jul 12, 2022 at 12:14:27PM -0300, André Almeida wrote:
> > > > Hi Sebin,
> > > >
> > > > Às 10:29 de 10/07/22,
Am 15.07.22 um 22:04 schrieb Ruijing Dong:
From VCN4, AMDGPU_HW_IP_VCN_UNIFIED is used to support
both encoding and decoding jobs, it re-uses the same
queue number of AMDGPU_HW_IP_VCN_ENC.
link: https://gitlab.freedesktop.org/mesa/drm/-/merge_requests/245/commits
Signed-off-by: Ruijing Dong
nouveau has additional debug variables to consider:
drivers/gpu/drm/nouveau/include/nvkm/core/device.h
131:if (_device->debug >= (l)) \
drivers/gpu/drm/nouveau/include/nvkm/core/client.h
39: if (_client->debug >= NV_DBG_##l)
Change nvkm_subdev.debug to a ulong, so dyndbg can maybe use it.
Move macro decl from nv-drm.c to subdev.c, and add a struct
ddebug_classes_bitmap_param and a module_param_cb() that creates the
sysfs-knob.
Finally, in nvkm_subdev_ctor(), *attempt* to set dyndbg's pointer to
the debug address, so
add new flag, and OR it into _DPRINTK_FLAGS_ENABLED definition
CC: vincent.whitchu...@axis.com
Signed-off-by: Jim Cromie
---
include/linux/dynamic_debug.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index
ddebug_trace() currently issues a single printk:console event.
Replace that, adding include/trace/events/dyndbg.h, which defines 2
new events:
- dyndbg:prdbg - from trace_prdbg() - if !dev
- dyndbg:devdbg - from trace_devdbg() - if !!dev
This links the legacy pr_debug API to tracefs, via
---
.../drm/nouveau/include/nvkm/core/subdev.h| 2 +-
drivers/gpu/drm/nouveau/nouveau_drm.c | 7 --
drivers/gpu/drm/nouveau/nvkm/core/subdev.c| 23 +++
3 files changed, 24 insertions(+), 8 deletions(-)
diff --git
drm_print defines all of these:
drm_dbg_{core,kms,prime,atomic,vbl,lease,_dp,_drmres}
but not drm_dbg_driver itself, which was the original drm_dbg.
To improve namespace symmetry, change the drm_dbg defn to
drm_dbg_driver, and redef grandfathered name to symmetric one.
This may help with
clone the nvkm_printk,_,__ macro ladder into nvkm_drmdbg,_,__.
And alter debug, trace, spam macros to use the renamed ladder.
This *sets-up* (not done yet) to remove the _subdev->debug >= (l)
condition, once the bitmap-param is wired up correctly, and figured
into dyndbg's jump-label enablement.
Undo the 1-line change that reduced count of prdbgs from 632 to 119.
ie: s/NV_SUBDEV_DBG_##l/NV_DBG_##l/
So heres what happened: new symbol is 15 (or 10), and fails this macro
test, so gets compiled out, and the dev_dbg is excluded.
if (CONFIG_NOUVEAU_DEBUG >= (l) && _subdev->debug >=
clone the nvkm_printk,_,__ macro ladder into nvkm_drmdbg,_,__.
And alter debug, trace, spam macros to use the renamed ladder.
This *sets-up* to remove the _subdev->debug >= (l) condition from the
__ macro, once the bitmap-param is wired up correctly (pointing at the
right state-bit-vector), and
These 2 macros formerly used dev_info, and they still check
subdev->debug to gate the printing. So dyndbg control is redundant
ATM (and possibly confusing, since its off by default).
prdbg count is up from 3, or from 65 (with VMM_DEBUG here)
[7.765379] dyndbg: 516 debug prints in module
Undo the 1-line change that reduced count of prdbgs from 632 to 119.
ie: s/NV_SUBDEV_DBG_##l/NV_DBG_##l/
So heres what happened: new symbol is 15 (or 10), and fails this macro
test, so gets compiled out, and the dev_dbg is excluded.
if (CONFIG_NOUVEAU_DEBUG >= (l) && _subdev->debug >=
Distinguish the condition: _DPRINTK_FLAGS_ENABLED from the bit:
_DPRINTK_FLAGS_PRINT, and re-define former in terms of latter, in
preparation to add a 2nd bit: _DPRINTK_FLAGS_TRACE
Update JUMP_LABEL code block to check _DPRINTK_FLAGS_ENABLED symbol.
Also add a 'K' to get new symbol
These 2 macros used drm_debug_enabled() on DRM_UT_{DRIVER,ATOMIC}
respectively, replace those with drm_dbg_##cat invocations.
this results in new class'd prdbg callsites:
:#> grep nouveau /proc/dynamic_debug/control | grep class | wc
1161130 15584
:#> grep nouveau
1st, internals:
adds: ddebug_trace()
uses trace_console() temporarily to issue printk:console event
uses internal-ish __ftrace_trace_stack code:
4-context buffer stack, barriers per Steve Rostedt
call it from new mid-layer funcs:
ddebug_printk() - ddebug_trace or vprintk (to syslog)
clone DRM.debug interface to DRM.tracebits: ie declare __drm_trace,
map its bits to drm-debug-categories, except this interface enables
messages to tracefs, not to syslog.
1- we reuse the drm_debug_classes class-map added previously.
this reflects the single source of both syslog/trace events
nouveau has additional debug variables to consider:
drivers/gpu/drm/nouveau/include/nvkm/core/device.h
131:if (_device->debug >= (l)) \
drivers/gpu/drm/nouveau/include/nvkm/core/client.h
39: if (_client->debug >= NV_DBG_##l)
In order to use dynamic-debug's jump-label optimization in drm-debug,
its clarifying to refine drm_debug_enabled into 3 uses:
1. drm_debug_enabled - legacy, public
2. __drm_debug_enabled - optimized for dyndbg jump-label enablement.
3. _drm_debug_enabled - pr_debug instrumented, observable
1.
These 2 macros used drm_debug_enabled() on DRM_UT_{DRIVER,ATOMIC}
respectively, replace those with drm_dbg_##cat invocations.
this results in new class'd prdbg callsites:
:#> grep nouveau /proc/dynamic_debug/control | grep class | wc
1161130 15584
:#> grep nouveau
adds: ddebug_trace()
uses trace_console() temporarily to issue printk:console event
uses internal-ish __ftrace_trace_stack code:
4-context buffer stack, barriers per Steve Rostedt
call it from new funcs:
ddebug_printk() - print to both syslog/tracefs
ddebug_dev_printk() - dev-print to
Add include/trace/events/drm.h, with 2 new events: drm_debug() &
drm_devdbg(), and call them from drm_dbg() & drm_dev_dbg(). This is
easy, cuz the callers already build the vaf that the callee wants.
This allows the 3-5k drm.debug/on-dyndbg callsites to independently
(re-)direct messages to
clone DRM.debug interface to DRM.tracebits: ie map bits to
drm-debug-categories, except this interface enables messages to
tracefs, not to syslog.
1- we reuse the class-map added previously.
this reflects the single source of both syslog/trace events
2- add a 2nd struct
From: "Steven Rostedt (Google)"
There's several places that open code the following logic:
TP_STRUCT__entry(__dynamic_array(char, msg, MSG_MAX)),
TP_fast_assign(vsnprintf(__get_str(msg), MSG_MAX, vaf->fmt, *vaf->va);)
To load a string created by variable array va_list.
The main issue with
Distinguish the condition: _DPRINTK_FLAGS_ENABLED from the bit:
_DPRINTK_FLAGS_PRINT, and re-define former in terms of latter, in
preparation to add a 2nd bit: _DPRINTK_FLAGS_TRACE
Update JUMP_LABEL code block to check _DPRINTK_FLAGS_ENABLED symbol.
Also add a 'K' to get new symbol
add new flag, and OR it into _DPRINTK_FLAGS_ENABLED definition
CC: vincent.whitchu...@axis.com
Signed-off-by: Jim Cromie
---
include/linux/dynamic_debug.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index
These 2 macros formerly used dev_info, and they still check
subdev->debug to gate the printing. So dyndbg control is redundant
ATM (and possibly confusing, since its off by default).
prdbg count is up from 3, or from 65 (with VMM_DEBUG here)
[7.765379] dyndbg: 516 debug prints in module
upgrade the callchain to drm_dbg() and drm_dev_dbg(); add a struct
_ddebug ptr parameter to them, and supply that additional param by
replacing the '_no_desc' flavor of dyndbg Factory macro currently used
with the flavor that supplies the descriptor.
NOTES:
The descriptor gives these fns access
upgrade the callchain to drm_dbg() and drm_dev_dbg(); add a struct
_ddebug ptr parameter to them, and supply that additional param by
replacing the '_no_desc' flavor of dyndbg Factory macro currently used
with the flavor that supplies the descriptor.
NOTES:
The descriptor gives these fns access
In order to use dynamic-debug's jump-label optimization in drm-debug,
its clarifying to refine drm_debug_enabled into 3 uses:
1. drm_debug_enabled - legacy, public
2. __drm_debug_enabled - optimized for dyndbg jump-label enablement.
3. _drm_debug_enabled - pr_debug instrumented, observable
1.
drm_print defines all of these:
drm_dbg_{core,kms,prime,atomic,vbl,lease,_dp,_drmres}
but not drm_dbg_driver itself, since it was the original drm_dbg.
To improve namespace symmetry, change the drm_dbg defn to
drm_dbg_driver, and redef grandfathered name to symmetric one.
This will help
ddebug_trace() currently issues a single printk:console event.
Replace that, adding include/trace/events/dyndbg.h, which defines 2
new events:
- dyndbg:prdbg - from trace_prdbg() - if !dev
- dyndbg:devdbg - from trace_devdbg() - if !!dev
This links the legacy pr_debug API to tracefs, via
Add an explanation of the new "class CLASS_NAME" syntax and meaning,
noting that the module determines if CLASS_NAME applies to it.
Signed-off-by: Jim Cromie
---
Documentation/admin-guide/dynamic-debug-howto.rst | 11 +++
1 file changed, 11 insertions(+)
diff --git
Add module-to-class validation:
#> echo class DRM_UT_KMS +p > /proc/dynamic_debug/control
If a query has "class FOO", then ddebug_find_valid_class(), called
from ddebug_change(), requires that FOO is known to module X,
otherwize the query is skipped entirely for X. This protects each
module's
For CONFIG_DRM_USE_DYNAMIC_DEBUG=y, wrap __drm_dbg() & __drm_dev_dbg()
in one of dyndbg's Factory macros: _dynamic_func_call_no_desc().
This adds the callsite descriptor into the code, and an entry for each
into /proc/dynamic_debug/control.
#> echo class DRM_UT_ATOMIC +p >
change drm_dev_dbg & drm_dbg to macros, which forward to the renamed
functions (with __ prefix added).
Those functions sit below the categorized layer of macros implementing
the DRM debug.category API, and implement most of it. These are good
places to insert dynamic-debug jump-label mechanics,
drm_print.c calls pr_debug() just once, from __drm_printfn_debug(),
which is a generic/service fn. The callsite is compile-time enabled
by DEBUG in both DYNAMIC_DEBUG=y/n builds.
For dyndbg builds, reverting this callsite back to bare printk is
correcting a few anti-features:
1- callsite is
drm_print.c calls pr_debug() just once, from __drm_printfn_debug(),
which is a generic/service fn. The callsite is compile-time enabled
by DEBUG in both DYNAMIC_DEBUG=y/n builds.
For dyndbg builds, reverting this callsite back to bare printk is
correcting a few anti-features:
1- callsite is
lkp robot told me:
>> drivers/gpu/drm/drm_ioc32.c:989:2:
error: call to undeclared function '_dynamic_func_call_cls';
ISO C99 and later do not support implicit function declarations
[-Wimplicit-function-declaration]
DRM_DEBUG("comm=\"%s\", pid=%d, dev=0x%lx, auth=%d, %s\n",
lkp robot told me:
>> drivers/gpu/drm/drm_ioc32.c:989:2:
error: call to undeclared function '_dynamic_func_call_cls';
ISO C99 and later do not support implicit function declarations
[-Wimplicit-function-declaration]
DRM_DEBUG("comm=\"%s\", pid=%d, dev=0x%lx, auth=%d, %s\n",
enum drm_debug_category has 10 categories, but is initialized with
bitmasks which require 10 bits of underlying storage. By using
natural enumeration, and moving the BIT(cat) into drm_debug_enabled(),
the enum fits in 4 bits, allowing the category to be represented
directly in pr_debug callsites,
Add ddebug_attach_module_classes(), call it from ddebug_add_module().
It scans the classes/section its given, finds records where the
module-name matches the module being added, and adds them to the
module's maps list. No locking here, since the record
isn't yet linked into the ddebug_tables
Add kernel_param_ops and callbacks to apply a class-map to a
sysfs-node, which then can control classes defined in that class-map.
This supports uses like:
echo 0x3 > /sys/module/drm/parameters/debug
IE add these:
- int param_set_dyndbg_classes()
- int param_get_dyndbg_classes()
- struct
Use DECLARE_DYNDBG_CLASSMAP across DRM:
- in .c files, since macro defines/initializes a record
- in drivers, $mod_{drv,drm,param}.c
ie where param setup is done (since a class-bitmap is a param)
- in drm/drm_print.c, since thats where it
adds the class-bitmap, and replaces
Rework/modernize docs:
- use /proc/dynamic_debug/control in examples
its *always* there (when dyndbg is config'd), even when is not.
drop talk, its a distraction here.
- read before write. Viewing before Controlling.
control file as Catalog.
- focus on use by a system
Like existing sections, particularly __dyndbg, this new one is an
array/address and its length. In a close imitation of __dyndbg
handling, these are defined, then passed around, as follows:
vmlinux.lds.h:
KEEP the new section, which also silences orphan section warning on
loadable modules. Add
Demonstrate use of DECLARE_DYNDBG_CLASSMAP macro, and expose them as
sysfs-nodes for testing.
For each of the 4 class-map-types:
- declare a class-map of that type,
- declare the enum corresponding to those class-names
- share _base across 0..30 range
- add a __pr_debug_cls() call for
For selftest purposes, add __pr_debug_cls(class, fmt, ...)
I didn't think we'd need to define this, since DRM effectively has it
already in drm_dbg, drm_devdbg. But test_dynamic_debug needs it in
order to demonstrate all the moving parts.
Note the __ prefix; its not intended for general use, at
Provide a simple module to allow testing DYNAMIC_DEBUG behavior. It
calls do_prints() from module-init, and with a sysfs-node.
dmesg -C
dmesg -w &
modprobe test_dynamic_debug dyndbg=+p
echo 1 > /sys/module/dynamic_debug/parameters/verbose
cat
DECLARE_DYNDBG_CLASSMAP lets modules declare a set of classnames, this
opt-in authorizes dyndbg to allow enabling of prdbgs by their class:
:#> echo class DRM_UT_KMS +p > /proc/dynamic_debug/control
This is just the setup; following commits deliver.
The macro declares and initializes a
This exported fn is unused, and will not be needed. Lets dump it.
The export was added to let drm control pr_debugs, as part of using
them to avoid drm_debug_enabled overheads. But its better to just
implement the drm.debug bitmap interface, then its available for
everyone.
Fixes: a2d375eda771
DRM issues ~10 exclusive categories of debug messages; to represent
this directly in dyndbg, add a new field: struct _ddebug.class_id:5.
This gives us 32 classes, which is a practical usability limit
with a bitmap interface:
#> echo 0x012345678 > /sys/module/drm/parameters/debug
All existing
dyndbg's control-parser: ddebug_parse_query(), requires that search
terms: module, func, file, lineno, are used only once in a query; a
thing cannot be named both foo and bar.
The cited commit added an overriding module modname, taken from the
module loader, which is authoritative. So it set
`cat control` currently does octal escape, so '\n' becomes "\012".
Change this to display as "\n" instead, which reads much cleaner.
:#> head -n7 /proc/dynamic_debug/control
# filename:lineno [module]function flags format
init/main.c:1179 [main]initcall_blacklist =_ "blacklisting
Walk the module's vector of callsites backwards; ie N..0. This
"corrects" the backwards appearance of a module's prdbg vector when
walked 0..N. I think this is due to linker mechanics, which I'm
inclined to treat as immutable, and the order is fixable in display.
No functional changes.
/proc/dynamic_debug/control walks the prdbg catalog in "reverse",
fix this by adding new ddebug_tables to tail of list.
This puts init/main.c entries 1st, which looks intentional.
no functional changes.
Signed-off-by: Jim Cromie
---
lib/dynamic_debug.c | 2 +-
1 file changed, 1 insertion(+),
1 - 100 of 104 matches
Mail list logo
