I'm running a DPDK process on a Linux and tried to follow the example down below to analysis core effiency.
https://software.intel.com/content/www/us/en/develop/documentation/vtune-cookbook/top/methodologies/core-utilization-in-dpdk-apps.html#core-utilization-in-dpdk-apps_RX
I ran the program on Ubuntu 20.04 and copied the file back to my windows laptop due to the lack of GUI components. And I can't get the DPDK Rx Spin Time shown before.
vtune results
warning logs
It's because of the warning logs. or am I missing something? Any help will be grateful.
Please check that application you are profiling contains the necessary callbacks for RX and TX tracing.
To enable RX burst statistic collection in VTune Profiler you need:
build DPDK with with the CONFIG_RTE_ETHDEV_RXTX_CALLBACKS and CONFIG_RTE_ETHDEV_PROFILE_WITH_VTUNE options enabled
rebuild your test application with this DPDK
run VTune I/O analysis
To check that VTune profiling is enabled ran:
nm <test_app> | grep profile_hook_rx_burst_cb
Related
I have a Qualcomm Development board with a Kryo 680 processor running a userdebug build of Android 11. I want to run some programs (e.g., benchmarks) and profile them using the ARM Streamline program. Unfortunately, some PMU registers return zero values.
Zero PMU values
I am getting the following warnings from Streamline.
Streamline Warnings
Warning 1: No Perf PMUs detected
Could not detect any Perf PMUs in /sys/bus/event_source/devices/ but the system contains recognised CPUs. The system may not support perf hardware counters. Check CONFIG_HW_PERF_EVENTS is set and that the PMU is configured in the target device tree.
Warning 2: Profiling Source
Using perf API for primary data source
Warning 3: Atrace is disabled
Unable to locate notify.dex
I am unsure of what to change in order to access the PMU counters. Is it an issue of gator? I am the pre-compiled version of gator provided with Streamline 8.0.
EDIT: Some more information printed by the gator daemon in the adb shell.
Unable to enable 1 perf groups due to them being reported as being disabled due to conflict or insufficient resources.
Another process may be using one or more perf counters.
Use `lsof|grep perf_event` (if available) to find other processes that may be using perf counters.
Not all event data may be available in the capture.
See debug log for more information.
The printout of lsof|grep perf_event is the following.
Binder:7545_3 7545 system 101u 0000 0,13 0t0 15649 anon_inode:[perf_event]
Binder:7545_3 7545 system 103u 0000 0,13 0t0 15649 anon_inode:[perf_event]
I have a problem with stability running TI AM5728 based custom board, similar to the Beaglebone X15. RTOS SW is running on one Cortex-A15 core MPU0 and sporadically (most often after several hours) freezes. When freezes it is impossible to connect to the MPU0 target by debugger, at the same time I can without any problems connect to the MPU1.
Debugger error:
CortexA15_0: Trouble Halting Target CPU: (Error -1323 # 0x1386AC)
Device failed to enter debug/halt mode because pipeline is stalled.
Power-cycle the board. If error persists, confirm configuration and/or
try more reliable JTAG settings (e.g. lower TCLK). (Emulation package
6.0.504.1)
For test purposes, I have started the simple program on the MPU1, and when MPU0 freezes MPU1 continue normal operation. WFE and WFI flag for MPU0 is inactive, moreover, I have made the additional test with trying to put MPU1 to the WFI/FORCED_OFF state. However, I still can connect with debugger and wakeup it from the FORCED_OFF state, as described in the technical manual.
I have dumped the registers by connection to the CS_DAP_DebugSS and have not found anything special. Register dump attached:
MPU_PRCM_PRM_C0_PM_CPU0_PWRSTCTRL
MPU_PRCM_DEVICE_PRM_RSTST
MPU_WUGEN_WKG_CONTROL_0
MPU_PRCM_CM_C0_CM_CPU0_CLKSTCTRL
What can be the potential stuck problem of just one core with failed attempts to connect with the debugger and second core running without problems?
Which hardware/software problem can potentially cause such behavior?
Thank you for any suggestions.
I just encounter the exact same problem.
Did you check your code at the address provided with the JTAG error (Error -1323 # 0x1386AC)? In my case it is an GPMC access, to a FPGA, which I can still access through CS_DAP_DebugSS.
I'm currently looking at errata i878, from revision L of the document. As it can take more than 48h to hang under stress test, I won't blindly apply the workaround. I'll modify my test, based on i878, trying to increase the failure rate, then I'll apply the workaround.
We use the rsyslogd daemon for logging debug messages in several applications. With full debug on, the server will hang in the openlog() call being made in the application to log messages. Looks to be doing a lock in the kernel library code in glibc.
Is this a known issue under load or are we exposing some contention issue in the kernel? RHEL 6.4 running kernel 2.6.32-358.2.1 (i386).
rsyslog version was 8.4.1 but we upgraded to latest this afternoon 8.17 and are still running tests to see if the problem continues.
To start with - I don't have JTAG hardware debugger.
What I have:
Pandaboard and serial-USB cable to connect to console and my computer with Freebsd and GNU/Linux distribution.
What I'm looking for
- convinient way to trace/debug bootprocess inside FreeBSD kernel ( I'm mostly interested in this fragment: https://github.com/freebsd/freebsd/blob/master/sys/arm/arm/locore-v6.S and https://github.com/freebsd/freebsd/blob/master/sys/arm/arm/mp_machdep.c as I'm, going to modyfy those files ).
Based on my experience, there are few ways:
KDB / DDB: add call kdb_enter("A", "XYZ") to stop processing and enter interactive debug mode of DDB via serial.
printf-s in machine dependent (mach_dep) code
bootverbose, BUSDEBUG, VERBOSE_SYSINIT in machine independent code
Also it's worth to mention that DDB code contains functions to print registers, stack trace and etc.
I am new to the RTOS world and working on the eval version of vxworks 6.7. I don't know How to turn on the wdb debugging for my bootloader which has troubles loading my network driver. I hope someone can help me with a quick tips.
Thank you
Are you connected via serial for debugging? If not, it may be impossible to debug networking issues. wdb runs on host in eclipse and connects to device (target) via serial or ethernet.
Anyway you turn on wdb support via the project when you build the bootloader.