- kernelnewbies@kernelnewbies.org - Kernelnewbies Mailing Lists

how to change the tty dev color
by Dileep Sankhla Aug. 19, 2024

Aug. 19, 2024

hi, how to change the tty dev color which we get when we press ctrl + alt + f2/f3? -- Regards, Dileep

1 0

Contributors to Raam Computer Software System Core are welcome
by Dileep Sankhla Aug. 7, 2024

Aug. 7, 2024

Raam Raam sa (greeting with God's name :) ) Raam Computer Software System and its Core are different from the (Unix) operating system and its kernel. There are many errors in the drivers that need to be corrected and new concepts are needed to be discussed before being implemented. To take this project as a full-time company, I need a co-founder and/or first of its developers. Contributions are helpful in this case. Project repository: https://github.com/robstat7/Raam Regards, Dileep

1 0

[PATCH v9-resend 00/54] fix CONFIG_DRM_USE_DYNAMIC_DEBUG=y
by Jim Cromie July 16, 2024

July 16, 2024

resending to fix double-copies of a dozen patches. added 2 squash-ins to address Ville's designated-initializer comment. This fixes dynamic-debug support for DRM.debug, added via classmaps. commit bb2ff6c27bc9 (drm: Disable dynamic debug as broken) CONFIG_DRM_USE_DYNAMIC_DEBUG=y was marked broken because drm.debug=val was applied when drm.ko was modprobed; too early for the yet-to-load drivers, which thus missed the enablement. My testing with /etc/modprobe.d/ entries and modprobes with dyndbg=$querycmd options obscured this omission. The fix is to replace invocations of DECLARE_DYNDBG_CLASSMAP with DYNDBG_CLASSMAP_DEFINE for core, and DYNDBG_CLASSMAP_USE for drivers. The distinction allows dyndbg to also handle the users properly. DRM is the only current classmaps user, and is not actually using it, so if you think DRM could benefit from zero-off-cost debugs based on static-keys, please test. There is also a no-DRM-involved selftest script: [root@v6 b0-dd]# V=0 ./tools/testing/selftests/dynamic_debug/dyndbg_selftest.sh # consulting KCONFIG_CONFIG: .config # BASIC_TESTS : 0 matches on =p : 14 matches on =p : 0 matches on =p : 21 matches on =mf : 0 matches on =ml : 6 matches on =mfl ... # Done on: Sun Jun 30 10:34:24 PM MDT 2024 HISTORY 9/4/22 - ee879be38bc8..ace7c4bbb240 commited - classmaps-v1 dyndbg parts 9/11/22 - 0406faf25fb1..16deeb8e18ca commited - classmaps-v1 drm parts https://lore.kernel.org/lkml/Y3XUrOGAV4I7bB3M@kroah.com/ greg k-h says: This should go through the drm tree now. The rest probably should also go that way and not through my tree as well. https://lore.kernel.org/lkml/20221206003424.592078-1-jim.cromie@gmail.com/ v1- RFC adds DYNDBG_CLASSMAP_DEFINE + test-submod to recap DRM failure https://lore.kernel.org/lkml/20230113193016.749791-1-jim.cromie@gmail.com/ v2- w RFC on "tolerate toggled state" https://lore.kernel.org/lkml/Y8aNMxHpvZ8qecSc@hirez.programming.kicks-ass.n… - PeterZ - nacks tolerance of insane/uninit static-key state https://lore.kernel.org/lkml/8ca08fba-1120-ca86-6129-0b33afb4a1da@akamai.co… - JasonB diagnoses prob - set jump-label b4 init 7deabd674988 dyndbg: use the module notifier callbacks - JasonB lands fix for my problem he moves dyndbg to use notifiers to do init, like & after jump-labels https://lore.kernel.org/lkml/20230125203743.564009-20-jim.cromie@gmail.com/ v3- probing, workaround-ish https://lore.kernel.org/lkml/20230713163626.31338-1-jim.cromie@gmail.com/ v4 - 7/13/23 - had extra/unused __UNIQUE_ID warnings/errs on lkp-tested arches due to unmatched __used marks - RandyD doc fixes, thx. https://lore.kernel.org/lkml/20230801170255.163237-1-jim.cromie@gmail.com/ v5 - 8/1/23 - lkp-test reported panics-on-boot https://lore.kernel.org/lkml/202308031432.fcb4197-oliver.sang@intel.com/ - DRM=y in apply-params - missing align(8) in init-macro, failed only for builtin modules https://lore.kernel.org/lkml/20230911230838.14461-1-jim.cromie@gmail.com/ v6 - 9/11/23 - no feedback v7[a-d] - attempts to get into/thru DRM patchwork CI.. - "jenius" struck, I preserved DECLARE_DYNDBG_CLASSMAP til later v8[a-i] - added tools/testing/selftests/dynamic_debug/* - now turnkey testable without DRM CLASSMAPS FROM THE TOP dynamic-debug classmap's primary goal was to bring zero-off-cost debugs, via static-keys, to DRM. drm.debug: is ~5000 invocations of debug-macros across core, drivers, helpers; each in 1 of 10 exclusive categories: DRM_UT_*, kept in an enum/int, and passed in 1st macro-arg, as a builtin-constant. The 10 categories are all controlled together, by bits 0..9 in a sysfs knob. drm.debug=0x1ff # bootarg echo 0x4 > /sys/module/drm/parameters/debug # run-time setting Keeping all that unchanged was a firm design requirement for classmaps. Below the sysfs interface, classmaps are exposed in the >control grammar with a new "class" keyword. This is mostly like the other selector keywords, differing by: a- classnames are client/subsystem/domain defined, not code-name-structural. the classnames are global, across system IOW: "class DRM_UT_CORE" selects on any module which knows the class b- classes are protected from unqualified modification. # cannot disable any DRM (or other) classes without saying so echo -p > /proc/dynamic_debug/control c- because b, modules must opt-in so dyndbg knows their classnames. without names, dyndbg cannot lookup the classid & change the class. d- classes don't have wildcards - add if needed. DRM uses "${SUBSYS}_${CATNAME}" probably more useful with "${TOP}_${MID}_${LOW}" classnames nobody's sure what _UT_ is. API in use: DYNDBG_CLASSMAP_* macros are all file-scope declarators. 1. DYNDBG_CLASSMAP_DEFINE(drm_debug_classes, ...); 2. DYNDBG_CLASSMAP_USE(drm_debug_classes); Classmaps get DEFINEd once (in drm.ko for core) and USEd (in drivers and helpers), these declarations 1. define and export a classmap (in core module), and 2. refer to the exported class-struct from the other modules. They both tell dynamic-debug that the module has some of these class'd pr_debugs, so dyndbg can use the classmap's names to validate >control inputs and change the callsites. This is the opt-in. The distinction allows USErs to act differently than the DEFINEr; they have to follow the ref back to the DEFINEing module, find the kparam connected to the classmap, and lookup and apply its modprobed value. (this is the bug-fix). Dyndbg uses the classnames to validate "class FOO" >control inputs, and apply the changes to each module that has DEFINEd or USEd the classmap. This makes classmaps opt-in: modules must _DEFINE or _USE a classmap for their class'd pr_debug()s to be >control'd. NOTE: __pr_dbg_class(1, "const-int unreachable class 1"); is legal, but not controllable unless the const 1 has been mapped to a _DEFINE'd classname. NB: and __pr_dbg_class(i++, "undeclared class") is illegal. In drm_print.c we have: (theres room for better words...) /* classnames must match value-symbols of enum drm_debug_category */ DRM_CLASSMAP_DEFINE(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS, DRM_UT_CORE, // _base /* this effectively names the bits in drm.debug */ "DRM_UT_CORE", "DRM_UT_DRIVER", "DRM_UT_KMS", "DRM_UT_PRIME", "DRM_UT_ATOMIC", "DRM_UT_VBL", "DRM_UT_STATE", "DRM_UT_LEASE", "DRM_UT_DP", "DRM_UT_DRMRES"); This maps the sequence of "classnames" to ints starting with DRM_UT_CORE. other _bases allow sharing the per-module 0..62 class-id space. (63 is default/unclassed/common prdbg). Only complete, linear maps are recommended. This suits DRM. DYNDBG_CLASSMAP_PARAM_REF() creates the sysfs-kparam classbits knob, binding the extern'd long-int/bitvec to the classmap. The extern insures that old users of __drm_debug can still check its value. DRM's categories are independent of each other. The other possible classmap-type/behavior is "related", ie somehow "ordered": V3>V2. The relatedness of classes in a classmap is enforced at the kparam, where they are all set together, not at the >control interface. THE PATCHSET has 2 halves: 1- dynamic-debug fix - API change The root cause was DECLARE_DYNDBG_CLASSMAP tried to do too much, and its use in both core and drivers, helpers couldnt sort the difference. The fix is to replace it with DYNDBG_CLASSMAP_DEFINE in core, and DYNDBG_CLASSMAP_USE in drivers,helpers. The 1st differs from -v1 by exporting the classmap, allowing 2nd to ref it. They respectively add records to 2 ELF sections in the module. Now, dyndbg's on-modprobe handler follows the _USE/refs to the owning module, finds the controlling kparam: drm.debug, and applies its value thru the classmap, to the module's pr_debugs. A selftest script is included: :#> ./tools/testing/selftests/dynamic_debug/dyndbg_selftest.sh It recapitulates the DRM regression scenario using the 2 test modules. The test verifies that the dependent module is initialized properly from the parent's classmap kparam, and the classed prdbgs get enabled. This latest rev fixes the test for the various CONFIG_DYNAMIC_DEBUG* build combos, by skipping some subtests where the expected counts are wrong. Lukasz Bartosik caught this - thanks. CC: ukaszb(a)chromium.org And 2 tweaks to kdoc & howto, to steer api users away from using designated initializers to _DEFINE the classmap. 2- DRM fixes - use new api. a. update core/drivers to invoke DRM_CLASSMAP_DEFINE/_USE b. wrap DYNDBG_CLASSMAP_* with DRM_CLASSMAP_* - hide ifdef c. now with separate +DRM_CLASSMAP_USE patches for each driver/helper: d. and defer dropping DECLARE_DYNDBG_CLASSMAP til later Maybe theres a single place to invoke DRM_CLASSMAP_USE just once, perhaps from a client library c-file. I poked a little, didn't find it. It would be a bit obscured for an opt-in style declaration. Patches are against v6.10 theyre also at: tree/branch: https://github.com/jimc/linux.git dd-fix-9d and lkp-robot told me: [jimc:dd-fix-9d] BUILD SUCCESS 7c38f1d94f9919fec887113b620b83d60061c035 Finally, classmaps are in a meta-stable state right now; some governor might yet walk it over to the gravel pit out back. Tested-bys would help greatly, help get it off the fence it straddles. Please specify your test method: selftest or drm.debug=0x1ff boot. Next Im gonna try to haul this over to the freedesktop DRM-CI river, presuming I can find the way (accts,etc) Also entertaining Reviewed-bys :-} Jim Cromie (54): DYNAMIC-DEBUG parts: cleanup: docs/dyndbg: update examples \012 to \n test-dyndbg: fixup CLASSMAP usage error dyndbg: reword "class unknown," to "class:_UNKNOWN_" dyndbg: make ddebug_class_param union members same size dyndbg: replace classmap list with a vector prep: dyndbg: ddebug_apply_class_bitmap - add module arg, select on it dyndbg: split param_set_dyndbg_classes to _module & wrapper fns dyndbg: drop NUM_TYPE_ARRAY dyndbg: reduce verbose/debug clutter dyndbg: silence debugs with no-change updates dyndbg: tighten ddebug_class_name() 1st arg type dyndbg: tighten fn-sig of ddebug_apply_class_bitmap dyndbg: reduce verbose=3 messages in ddebug_add_module API changes & selftest: dyndbg-API: remove DD_CLASS_TYPE_(DISJOINT|LEVEL)_NAMES and code dyndbg-API: fix DECLARE_DYNDBG_CLASSMAP selftests-dyndbg: add tools/testing/selftests/dynamic_debug/* dyndbg-API: promote DYNDBG_CLASSMAP_PARAM to API dyndbg-doc: add classmap info to howto dyndbg: treat comma as a token separator selftests-dyndbg: add comma_terminator_tests dyndbg: split multi-query strings with % selftests-dyndbg: test_percent_splitting docs/dyndbg: explain new delimiters: comma, percent selftests-dyndbg: add test_mod_submod dyndbg-doc: explain flags parse 1st dyndbg: change __dynamic_func_call_cls* macros into expressions selftests-dyndbg: check KCONFIG_CONFIG to avoid silly fails dyndbg-selftest: reduce default verbosity DRM-parts: drm: use correct ccflags-y spelling drm-dyndbg: adapt drm core to use dyndbg classmaps-v2 drm-dyndbg: adapt DRM to invoke DYNDBG_CLASSMAP_PARAM drm-dyndbg: DRM_CLASSMAP_USE in amdgpu driver drm-dyndbg: DRM_CLASSMAP_USE in i915 driver drm-dyndbg: DRM_CLASSMAP_USE in drm_crtc_helper drm-dyndbg: DRM_CLASSMAP_USE in drm_dp_helper drm-dyndbg: DRM_CLASSMAP_USE in nouveau drm-print: workaround unused variable compiler meh drm-dyndbg: add DRM_CLASSMAP_USE to Xe driver drm-dyndbg: add DRM_CLASSMAP_USE to virtio_gpu drm-dyndbg: add DRM_CLASSMAP_USE to simpledrm drm-dyndbg: add DRM_CLASSMAP_USE to bochs drm-dyndbg: add DRM_CLASSMAP_USE to etnaviv drm-dyndbg: add DRM_CLASSMAP_USE to gma500 driver drm-dyndbg: add DRM_CLASSMAP_USE to radeon drm-dyndbg: add DRM_CLASSMAP_USE to vmwgfx driver drm-dyndbg: add DRM_CLASSMAP_USE to vkms driver drm-dyndbg: add DRM_CLASSMAP_USE to udl driver drm-dyndbg: add DRM_CLASSMAP_USE to mgag200 driver drm-dyndbg: add DRM_CLASSMAP_USE to the gud driver drm-dyndbg: add DRM_CLASSMAP_USE to the qxl driver drm-dyndbg: add DRM_CLASSMAP_USE to the drm_gem_shmem_helper driver drm: restore CONFIG_DRM_USE_DYNAMIC_DEBUG un-BROKEN added in -resend (will squash back in): dyndbg: tighten up kdoc about DYNDBG_CLASSMAP_* macros docs-dyndbg: improve howto classmaps api section .../admin-guide/dynamic-debug-howto.rst | 113 ++++- MAINTAINERS | 3 +- drivers/gpu/drm/Kconfig | 3 +- drivers/gpu/drm/Makefile | 3 +- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 12 +- drivers/gpu/drm/display/drm_dp_helper.c | 12 +- drivers/gpu/drm/drm_crtc_helper.c | 12 +- drivers/gpu/drm/drm_gem_shmem_helper.c | 2 + drivers/gpu/drm/drm_print.c | 38 +- drivers/gpu/drm/etnaviv/etnaviv_drv.c | 2 + drivers/gpu/drm/gma500/psb_drv.c | 2 + drivers/gpu/drm/gud/gud_drv.c | 2 + drivers/gpu/drm/i915/i915_params.c | 12 +- drivers/gpu/drm/mgag200/mgag200_drv.c | 2 + drivers/gpu/drm/nouveau/nouveau_drm.c | 12 +- drivers/gpu/drm/qxl/qxl_drv.c | 2 + drivers/gpu/drm/radeon/radeon_drv.c | 2 + drivers/gpu/drm/tiny/bochs.c | 2 + drivers/gpu/drm/tiny/simpledrm.c | 2 + drivers/gpu/drm/udl/udl_main.c | 2 + drivers/gpu/drm/virtio/virtgpu_drv.c | 2 + drivers/gpu/drm/vkms/vkms_drv.c | 2 + drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 2 + drivers/gpu/drm/xe/xe_drm_client.c | 2 + include/asm-generic/vmlinux.lds.h | 1 + include/drm/drm_print.h | 10 + include/linux/dynamic_debug.h | 145 ++++-- kernel/module/main.c | 3 + lib/Kconfig.debug | 24 +- lib/Makefile | 3 + lib/dynamic_debug.c | 436 +++++++++++------- lib/test_dynamic_debug.c | 131 +++--- lib/test_dynamic_debug_submod.c | 17 + tools/testing/selftests/Makefile | 1 + .../testing/selftests/dynamic_debug/Makefile | 9 + tools/testing/selftests/dynamic_debug/config | 2 + .../dynamic_debug/dyndbg_selftest.sh | 375 +++++++++++++++ 37 files changed, 1042 insertions(+), 363 deletions(-) create mode 100644 lib/test_dynamic_debug_submod.c create mode 100644 tools/testing/selftests/dynamic_debug/Makefile create mode 100644 tools/testing/selftests/dynamic_debug/config create mode 100755 tools/testing/selftests/dynamic_debug/dyndbg_selftest.sh -- 2.45.2

1 53

[PATCH v9-resend 01/54] docs/dyndbg: update examples \012 to \n
by Jim Cromie July 16, 2024

July 16, 2024

commit 47ea6f99d06e ("dyndbg: use ESCAPE_SPACE for cat control") changed the control-file to display format strings with "\n" rather than "\012". Update the docs to match the new reality. Signed-off-by: Jim Cromie <jim.cromie(a)gmail.com> --- Documentation/admin-guide/dynamic-debug-howto.rst | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/Documentation/admin-guide/dynamic-debug-howto.rst b/Documentation/admin-guide/dynamic-debug-howto.rst index 0e9b48daf690..6a8ce5a34382 100644 --- a/Documentation/admin-guide/dynamic-debug-howto.rst +++ b/Documentation/admin-guide/dynamic-debug-howto.rst @@ -52,12 +52,12 @@ query/commands to the control file. Example:: # grease the interface :#> alias ddcmd='echo $* > /proc/dynamic_debug/control' - :#> ddcmd '-p; module main func run* +p' + :#> ddcmd '-p; module main func run* +p' # disable all, then enable main :#> grep =p /proc/dynamic_debug/control - init/main.c:1424 [main]run_init_process =p " with arguments:\012" - init/main.c:1426 [main]run_init_process =p " %s\012" - init/main.c:1427 [main]run_init_process =p " with environment:\012" - init/main.c:1429 [main]run_init_process =p " %s\012" + init/main.c:1424 [main]run_init_process =p " with arguments:\n" + init/main.c:1426 [main]run_init_process =p " %s\n" + init/main.c:1427 [main]run_init_process =p " with environment:\n" + init/main.c:1429 [main]run_init_process =p " %s\n" Error messages go to console/syslog:: -- 2.45.2

1 0

Can I change PCIe TLP's Tag value?
by 김찬 July 9, 2024

July 9, 2024

Hello all, We are doing a test by modiying a simple PCIe device driver to do memory write and read. Write and read from to the device's PCIe core's internal register is ok but when we do memory write and read for the device's internal memory, the writes are ok (we can observer the result using jtag debugger) but the MemRd causes error (we checked using PCIe test equipment called VIAVI). The equipment support person said the error came out because the Tag value of the MemRd TLP is the same as the MemWr TLP's. So is there a method by which I can change the Tag value of the TLP? Thank you. Chan Kim

1 0

Request for information on using NVMe under linux
by Jamaleddine AMGHAR July 3, 2024

July 3, 2024

Hello, I am experiencing an abnormal performance issue with my Samsung SSD 970 EVO Plus 1TB (2B2QEXM7) on my Ubuntu 24.04 LTS system. My setup includes a 12th Gen Intel Core i7-12700 x 20 processor, and the SSD is connected to an M.2 M-key, type-2280 slot (PCIe Gen.3 x4 interface) that supports NVMe on the motherboard. Specifically, I have noticed a significantly low write speed of around 700MB/s on my Ubuntu system. After some research, it appears that many users face similar issues when using NVMe drives on Linux. In contrast, when I tested the same SSD on the same motherboard using a portable Windows OS, the write speed was approximately 3GB/s. Could you provide any methods to optimize the performance of my NVMe drive on Linux? Additionally, how can I update the NVMe driver on Linux using "nvme-cli"? Any advice or recommendations you have to address this issue would be greatly appreciated. Thank you for your assistance. Best regards, Jamaledd

4 4

sanity check typo patch "quired"
by daniel watson July 1, 2024

July 1, 2024

here's a patch to fix a typo in the memory management docs. i'm sending to this mailing list first for a sanity check. From: Daniel Watson <ozzloy(a)each.do> To: Jonathan Corbet <corbet(a)lwn.net>,linux-doc@vger.kernel.org,linux-kernel@vger.kernel.org Date: Wed, 26 Jun 2024 21:18:22 -0700 Subject: [PATCH] mm: docs: correct 'quired' to 'queried' Convert from the word "quired" to the word "queried" which makes more sense in this context. Signed-off-by: Daniel Watson <ozzloy(a)each.do> --- Documentation/admin-guide/mm/index.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/admin-guide/mm/index.rst b/Documentation/admin-guide/mm/index.rst index 1f883abf3f00f..8b35795b664be 100644 --- a/Documentation/admin-guide/mm/index.rst +++ b/Documentation/admin-guide/mm/index.rst @@ -10,7 +10,7 @@ processes address space and many other cool things. Linux memory management is a complex system with many configurable settings. Most of these settings are available via ``/proc`` -filesystem and can be quired and adjusted using ``sysctl``. These APIs +filesystem and can be queried and adjusted using ``sysctl``. These APIs are described in Documentation/admin-guide/sysctl/vm.rst and in `man 5 proc`_. .. _man 5 proc: http://man7.org/linux/man-pages/man5/proc.5.html -- 2.43.0

2 2

RISC-V and interrupts, constant rate vs. tickless vs. SIE=0
by Andras Pal June 28, 2024

June 28, 2024

Hi All, I'm compiling and installing the RISC-V (RV32IMAC) port of Linux to a custom FPGA-based SoC. However, during the ISA level simulations, there is an indication that do_idle() disables the supervisor interrupts by setting SIE=0 in the CSR sstatus, just before entering to WFI state. It happens right after starting the /init process from initrd, so when the (presumably) first U mode precess is executed and this process is just waiting from interrupts from the console (that is a 8250/16550, connected to SEI via PLIC). I tried both tickless and constant rate timers in Config > General setup > Timers subsystem, but both of them behaves the same. If the system is tickless, it might make sense to disable STIE in the CSR sie, but not SIE in sstatus... How can this issue be debugged or checked in more details, do you have any recommendations where to start? The kernel version is one of the most recent longterm one (6.6.32, to be precise). thanks in advance, Andras

1 0

Re: How to accout max_rss precisely
by Heran Yang June 17, 2024

June 17, 2024

Hi, and thanks for your reply. I totally forgot to take the dynamic loader into consideration, which is my bad. But another problem is that the peak value cannot align with the max_rss getting from `getrusage` function, which is ~1000KiB. I guess that it has some connection with max_rss inheriting, but I'm not sure about that. Do you have any opinion about it? 杨贺然 <herany1999(a)gmail.com> 于2024年6月4日周二 21:37写道： > Hi, and thanks for your reply. I totally forgot to take the dynamic loader > into consideration, which is my bad. > > But another problem is that the peak value cannot align with the max_rss > getting from `getrusage` function, which > is ~1000KiB. I guess that it has some connection with max_rss inheriting, > but I'm not sure about that. Do you have > any opinion about it? > > Valdis Klētnieks <valdis.kletnieks(a)vt.edu> 于2024年6月4日周二 01:44写道： > >> On Sat, 01 Jun 2024 15:01:32 +0800, 杨贺然 said: >> >> > // a.c >> > int main() {} >> > >> > It shows that `memory.peak` of this program is ~500KiB, which does not >> make >> > sense to me. >> >> Makes sense to me... >> >> [~] cat > testnull.c >> int main() {} >> [~] gcc testnull.c >> [~] ldd a.out >> linux-vdso.so.1 (0x00007efc6a650000) >> libc.so.6 => /lib64/libc.so.6 (0x00007efc6a43d000) >> /lib64/ld-linux-x86-64.so.2 (0x00007efc6a652000) >> [~] objdump -d a.out >> >> a.out: file format elf64-x86-64 >> >> >> Disassembly of section .init: >> >> 0000000000401000 <_init>: >> 401000: f3 0f 1e fa endbr64 >> 401004: 48 83 ec 08 sub $0x8,%rsp >> 401008: 48 8b 05 d1 2f 00 00 mov 0x2fd1(%rip),%rax # >> 403fe0 <__gmon_start__@Base> >> 40100f: 48 85 c0 test %rax,%rax >> 401012: 74 02 je 401016 <_init+0x16> >> 401014: ff d0 call *%rax >> 401016: 48 83 c4 08 add $0x8,%rsp >> 40101a: c3 ret >> >> Disassembly of section .text: >> >> 0000000000401020 <_start>: >> 401020: f3 0f 1e fa endbr64 >> 401024: 31 ed xor %ebp,%ebp >> 401026: 49 89 d1 mov %rdx,%r9 >> 401029: 5e pop %rsi >> 40102a: 48 89 e2 mov %rsp,%rdx >> 40102d: 48 83 e4 f0 and $0xfffffffffffffff0,%rsp >> 401031: 50 push %rax >> 401032: 54 push %rsp >> 401033: 45 31 c0 xor %r8d,%r8d >> 401036: 31 c9 xor %ecx,%ecx >> 401038: 48 c7 c7 06 11 40 00 mov $0x401106,%rdi >> 40103f: ff 15 93 2f 00 00 call *0x2f93(%rip) # >> 403fd8 <__libc_start_main@GLIBC_2.34> >> 401045: f4 hlt >> 401046: 66 2e 0f 1f 84 00 00 cs nopw 0x0(%rax,%rax,1) >> 40104d: 00 00 00 >> (.....) >> >> Basically, its not *really* a totally null program. You've got the >> dynamic >> loader ld-linux running first, which then *doesn't* run main() directly, >> but >> rather invokes _start, which needs to happen so that __libc_start_main >> can get >> called and initialize stuff lie stdio, malloc, and other such t hings, >> before >> it finally calls main(). >> >> Personally, I'm surprised that ld-linux and glibc initialization can >> finish >> without going over 500k - even more so if shared library text pages are >> included in memory.peak. Somebody else can wade into that mess, I admit >> having been around since kernel 2.5.47 or so, and I never did understand >> the >> memory accounting for shared text pages.... >> >>

2 2

DMA Engine - dealing with timeouts
by Anthony Clark June 10, 2024

June 10, 2024

Hey all, As a newbie, I'm trying to figure out how to properly deal with timeouts for dma_engine_submit(). I'm using a """prototype""" kernel module that sits on-tops of the Xilinx AXIDMA driver as part of Xilinx's Linux fork. They do a good job of merging with upstream kernels but there are some Xilinx-specific things and I apologize if some information is hard to parse. I believe my question is generic to the DMA Engine framework. This module, called "dma-proxy" is discussed a lot by Xilinx forums members but information doesn't typically flow back to users where there are fixes. Aside from the "dma-proxy" driver, Xilinx also includes a "AXIDMA Test" driver. Both drivers sit atop of the Xilinx DMA driver and do various things. The "dma-proxy" does some sharing of memory between userspace and the kernel but that's not really important to my question. First, this chain eventually resolves into `dma_engine_submit()`: ----------------------------------------------------------------- (~ https://github.com/Xilinx-Wiki-Projects/software-prototypes/blob/master/lin… ) sg_init_table(..., 1); sg_dma_address(... ) = foo.dma_handle; sg_dma_len(...t) = foo.length; chan_desc = dma_device->device_prep_slave_sg(..., ..., 1, ..., ..., NULL); if (! chan_desc) { printk(KERN_ERR "dmaengine_prep*() error\n"); else { ... } Then, the driver waits for the completion and prints an error if it cannot complete: ------------------------------------------------------------------------------------------------------------------- unsigned long timeout = msecs_to_jiffies(3000); timeout = wait_for_completion_timeout(foo.cmp, timeout); status = dma_async_is_tx_complete(..., ..., NULL, NULL); if (timeout == 0) { printk(KERN_ERR "DMA timed out\n"); } else { ... } ====== I cannot figure out what to do in the case of a timeout. It appears descriptors (chan_desc) are being leaked when completion cannot be completed. I see some patches to make the list of descriptors larger but it appears the default/configured is 255. So if I sit and timeout for 3sec * 255, I run out of descriptors and that DMA engine instance is no longer usable. It appears that even Xilinx's AXIDMA Test driver doesn't handle any sort of resource release or cleanup either: https://github.com/Xilinx/linux-xlnx/blob/master/drivers/dma/xilinx/axidmat… I hope someone can point me in the right direction so I can timeout nicely. Thanks! -- Anthony G. Clark Gtalk :: clark.anthony.g Phone :: 951 526 5237

1 0