Nx uses /dev/ttyTHS0 serial port to read the problem of kmalloc-256 increasing

[venceplace]

The nx version currently used is L4T 35.1.0

First check the current usage of kmalloc-256

Send the memory slabtop situation in the file

Using /dev/ttyTHS0, the baud rate is 460800

The other end of the serial port is connected to the PC, and the file is sent from the PC at the same time, and the baud rate is also 460800.

After closing minicom, kmalloc-256 is still not released.

[KevinFFF]

Hi venceplace,

Are you using the devkit or custom board for Xavier NX?

Is your issue about the serial communication or kmalloc-256 not released?

Could you help to verify with latest JP5.1.1(R35.3.1)?

[venceplace]

@KevinFFF

Xavier NX

1. The core boards you use directly are just the carrier boards;
2. The above data of Xavier NX is directly tested by minicom;
3. There is no time to help test JP5.1.1 (R35.3.1) for the time being, and it will only be used on JP5.0.2 (R35.1.0) in the short term.

[KevinFFF]

@venceplace

The core boards you use directly are just the carrier boards;

Do you mean that you are using the custom carrier board for Xavier NX?

@venceplace

The above data of Xavier NX is directly tested by minicom;

What I mean is to clarify what is your issue?

1. serial communication fail on /dev/ttyTHS0
2. kmalloc-256 not released after closing minicom

[venceplace]

1. We customized the carrier board ourselves, but the corresponding device tree file has not been changed.
2. Use minicomn to communicate with sscom on the PC; if you send a file to minicom with a baud rate of 460800 on sscom, you will see that the size of kmalloc-256 continues to grow (obviously increases), and the memory of kmalloc-256 after closing minicom No significant reduction. Neither sscom nor minicom have hardware streams open, 460800, 8N1.

[venceplace]

The minicom can communicate normally with the SSCOM of the PC, but the problem now is the memory leak of kmalloc-256.

[KevinFFF]

Thanks for your clarification.

So. the issue is about the memory leak of kmalloc-256.

Do you have devkit could be reproduced with the same behavior?

Could you also provide the full serial console log for further check?

[venceplace]

For the serial port, just do the following operations on the system,
“sudo systemctl disable nvgetty.service, sudo usermod -aG dialout robot”, others are consistent with the current system, there is no way to give logs in this regard, the only operation is to receive data through minicom and check the size change of kmalloc-256 through sudo slabtop Condition. You can check the pictures provided for your reference.

[venceplace]

I reopened kmemleak debugging, recompiled the kernel and got these logs.

creenshot of sudo dmesg execution result

cat /sys/kernel/debug/kmemleak screenshot

[venceplace]

unreferenced object 0xffff287d3ee64500 (size 256):
comm “hardirq”, pid 0, jiffies 4295062501 (age 1032.792s)
hex dump (first 32 bytes):
00 00 00 00 00 10 00 00 00 00 00 00 00 00 00 00 …
01 00 00 00 00 00 00 00 63 58 00 00 03 00 00 00 …cX…
backtrace:
[<00000000095b5309>] slab_post_alloc_hook+0x68/0x380
[<000000000e35ce8b>] __kmalloc+0x220/0x460
[<0000000065d0dcdf>] tegra_dma_prep_slave_sg+0x130/0x340
[<00000000335e7bdd>] tegra_uart_start_rx_dma+0xbc/0x140
[<00000000fc6a0321>] tegra_uart_isr+0x300/0x490
[<00000000c3e97a68>] __handle_irq_event_percpu+0x68/0x2a0
[<000000002686c20b>] handle_irq_event_percpu+0x40/0xa0
[<0000000032b93f1b>] handle_irq_event+0x50/0xf0
[<000000004a5ff1e5>] handle_fasteoi_irq+0xc0/0x170
[<00000000602ebf39>] generic_handle_irq+0x40/0x60
[<000000007789cf0e>] __handle_domain_irq+0x70/0xd0
[<000000009650dfdb>] efi_header_end+0xb0/0xf0
[<0000000090f1b002>] el1_irq+0xd0/0x180
[<0000000027c79014>] cpuidle_enter_state+0xb8/0x410
[<0000000060eb44a4>] cpuidle_enter+0x40/0x60
[<00000000a059e437>] call_cpuidle+0x44/0x80

[KevinFFF]

Do you use UART with DMA enabled and get kmalloc-256 memory leak issue?

[venceplace]

Yes. how to solve this problem

[venceplace]

Can anyone help with this issue?

[venceplace]

P3668-0001 for the core board, p3509-0000 for the carrier board

[KevinFFF]

There is no update from you for a period, assuming this is not an issue any more.
Hence we are closing this topic. If need further support, please open a new one.
Thanks

Could you help to provide the detailed reproduce steps on the devkit so that we could debug locally?