mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-02-03 23:40:14 +08:00
Merge pull request #1387 from bazz2/master
[bazz2-ed]Linux Kernel Testing and Debugging 4
This commit is contained in:
Xingyu.Wang
commit
0e88be8853
@ -1,144 +0,0 @@
|
||||
[bazz2 keep moving]
|
||||
Linux Kernel Testing and Debugging
|
||||
================================================================================
|
||||
### Auto Testing Tools ###
|
||||
|
||||
There are several automated testing tools and test infrastructures that you can chose from based on your specific testing needs. This section is intended to be a brief overview and not a detailed guide on how to use each of these.
|
||||
|
||||
#### [AuToTest][1] ####
|
||||
|
||||
> Autotest is a framework for fully automated testing. It is designed primarily to test the Linux kernel, though it is useful for many other functions such as qualifying new hardware. It is an open source project under the GPL. Autotest works in server-client mode. Autotest server can be configured to initiate, run, and monitor tests on several target systems running the autotest client. Autotest client can be run manually on a target system or via the server. Using this framework, new test cases can be added. Please [Autotest White Paper][2] for more information.
|
||||
|
||||
#### Linaro Automated Validation Architecture ####
|
||||
|
||||
> LAVA-Test Automated Testing Framework is a framework to help with automated installation and executions of tests. For example, running LTP in LAVA framework can be accomplished with a few commands. Running lava-test tool to install LTP will automatically install any dependencies, download the source for the recent release of LTP, compile it, and install the binaries in a self-contained area so that they can be removed easily when user runs uninstall. At this point running lava-test run with ltp test option will execute LTP tests and save results with an unique id that includes the test name, time/date stamp of the test execution. These results are saved for future reference. This is a good feature to find regressions, if any, between test runs. Summary of commands to run as an example:
|
||||
|
||||
Show a list of tests supported by lava-test:
|
||||
|
||||
lava-test list-tests
|
||||
|
||||
Install a new test:
|
||||
|
||||
lava-test install ltp
|
||||
|
||||
Run the test:
|
||||
|
||||
lava-test run ltp
|
||||
|
||||
Check results:
|
||||
|
||||
lava-test results show ltp-timestamp.0
|
||||
|
||||
Remove tests:
|
||||
|
||||
lava-test uninstall ltp
|
||||
|
||||
### Kernel Debug Features ###
|
||||
|
||||
Linux kernel includes several debugging features such as kmemcheck and kmemleak.
|
||||
|
||||
#### kmemcheck ####
|
||||
|
||||
> kmemcheck is a dynamic checking tool that detects and warns about some uses of uninitialized memory. It serves the same function as Valgrind's memcheck which is a userspace memory checker, where as kmemcheck checks kernel memory. CONFIG_KMEMCHECK kernel configuration option enables the kmemcheck debugging feature. Please read the Documentation/kmemcheck.txt for information on how to configure and use this feature, and how to interpret the reported results.
|
||||
|
||||
#### kmemleak ####
|
||||
|
||||
> kmemleak can be used to detect possible kernel memory leaks in a way similar to a tracing garbage collector. The difference between the tracing garbage collector and kmemleak is that the latter doesn't free orphan objects, instead it reports them in /sys/kernel/debug/kmemleak. A similar method of reporting and not freeing is used by the Valgrind's memcheck --leak-check to detect memory leaks in user-space applications. CONFIG_DEBUG_KMEMLEAK kernel configuration option enables the kmemleak debugging feature. Please read the Documentation/kmemleak.txt for information on how to configure and use this feature, and how to interpret the reported results.
|
||||
|
||||
### Kernel Debug Interfaces ###
|
||||
|
||||
Linux kernel has support for static and dynamic debugging via configuration options, debug APIs, interfaces, and frameworks. Let's learn more about each of these starting with the static options.
|
||||
|
||||
### Debug Configuration Options - Static ###
|
||||
|
||||
Linux kernel core and several Linux kernel modules, if not all, include kernel configuration options to debug. Several of these static debug options can be enabled at compile time. Debug messages are logged in dmesg buffer.
|
||||
|
||||
### Debug APIs ###
|
||||
|
||||
An example of Debug APIs is DMA-debug which is desiged for debugging driver dma api usage errors. When enabled, it keeps track of dma mappings per device, detects unmap attempts on addresses that aren't mapped, and missing mapping error checks in driver code after dma map attempts. CONFIG_HAVE_DMA_API_DEBUG and CONFIG_DMA_API_DEBUG kernel configuration options enable this feature on architectures that provide the support. With the CONFIG_DMA_API_DEBUG option enabled, the Debug-dma interfaces are called from DMA API. For example, when a driver calls dma_map_page() to map a dma buffer, dma_map_page() will call debug_dma_map_page() to start tracking the buffer until it gets released via dma_unmap_page() at a later time. For further reading on [Detecting silent data corruptions and memory leaks using DMA Debug API ][3]
|
||||
|
||||
### Dynamic Debug ###
|
||||
|
||||
Dynamic debug feature allows dynamically enabling/disabling pr_debug(), dev_dbg(), print_hex_dump_debug(), print_hex_dump_bytes() per-callsite. What this means is, a specific debug message can be enabled at run-time to learn more about a problem that is observed. This is great because, there is no need to re-compile the kernel with debug options enabled, then install the new kernel, only to find that the problem is no longer reproduciable. Once CONFIG_DYNAMIC_DEBUG is enabled in the kernel, dynamic debug feature enables a fine grain enable/disable of debug messages. /sys/kernel/debug/dynamic_debug/control is used to specify which pr_* messages are enabled. A quick summary of how to enable dynamic debug per call level, per module level is as follows:
|
||||
|
||||
Enable pr_debug() in kernel/power/suspend.c at line 340:
|
||||
|
||||
echo 'file suspend.c line 340 +p' > /sys/kernel/debug/dynamic_debug/control
|
||||
|
||||
Enable dynamic debug feature in a module at module load time
|
||||
|
||||
> Pass in dyndbg="plmft" to modprobe at the time module is being loaded.
|
||||
|
||||
Enable dynamic debug feature in a module to persist across reboots
|
||||
|
||||
> create or change modname.conf file in /etc/modprobe.d/ to add dyndbg="plmft" option. However for drivers that get loaded from initramfs, changing modname.conf is insufficient for the dynamic debug feature to persist across reboot. For such drivers, change grub to pass in module.dyndbg="+plmft" as a module option as a kernel boot parameter.
|
||||
|
||||
dynamic_debug.verbose=1 kernel boot option increases the verbosity of dynamic debug messages. Please consult the Documentation/dynamic-debug-howto.txt for more information on this feature.
|
||||
|
||||
### Tracepoints ###
|
||||
|
||||
So far we talked about various static and dynamic debug features. Both static debug options and debug hooks such as the DMA Debug API are either enabled or disabled at compile time. Both of these options require a new kernel to be compiled and installed. The dynamic debug feature eliminates the need for a recompile, however the debug code is compiled in with a conditional variable that controls whether or not the debug message gets printed. It helps that the messages can be enabled at run-time, however, the conditional code is executed at run-time to determine if the message needs to be printed. Tracepoint code on the otherhand can be triggered to be included at run-time only when the tracepoint is enabled. In other words, tracepoint code is different in that, it is inactive unless it is enabled. When it is enabled, code is modified to include the tracepoint code. It doesn't add any conditional logic overhead to determine whether or not to generate a trace message.
|
||||
|
||||
Please read [Tips on how to implement good tracepoint code][4] for more insight into how tracing works.
|
||||
|
||||
### Tracepoint mechanism ###
|
||||
|
||||
The tracepoints use jump-labels which is a code modification of a branch.
|
||||
|
||||
When it is disabled, the code path looks like:
|
||||
|
||||
[ code ]
|
||||
nop
|
||||
back:
|
||||
[ code ]
|
||||
return;
|
||||
tracepoint:
|
||||
[ tracepoint code ]
|
||||
jmp back;
|
||||
|
||||
When it is enabled, the code path looks like: (notice how the tracepoint code appears in the code path below)
|
||||
|
||||
[ code ]
|
||||
jmp tracepoint
|
||||
back:
|
||||
[ code ]
|
||||
return;
|
||||
tracepoint:
|
||||
[ tracepoint code ]
|
||||
jmp back;
|
||||
|
||||
### Linux PM Sub-system Testing ###
|
||||
|
||||
Using debug, dynamic debug, and tracing, let's run a few suspend to disk PM tests. When system is suspended, kernel creates hibernation image on disk, suspends and uses the image to restore the systerm state at resume time.
|
||||
|
||||
Enable logging time it takes to suspend and resume each device
|
||||
|
||||
echo 1 > /sys/power/pm_print_times
|
||||
|
||||
Run suspend to disk test in reboot mode
|
||||
|
||||
echo reboot > /sys/power/disk
|
||||
echo disk > /sys/power/state
|
||||
|
||||
Run suspend to disk test in shutdown mode - same as reboot, except requires powering on to resume
|
||||
|
||||
echo shutdown > /sys/power/disk
|
||||
echo disk > /sys/power/state
|
||||
|
||||
Run suspend to disk test in platform mode - more extensive and tests BIOS suspend and resume paths e.g: ACPI methods will be invoked. This is the recommended mode for hibernation so BIOS is informed and aware of suspend/resume action.
|
||||
|
||||
echo platform > /sys/power/disk
|
||||
echo disk > /sys/power/state
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via:http://www.linuxjournal.com/content/linux-kernel-testing-and-debugging?page=0,3
|
||||
|
||||
译者：[译者ID](https://github.com/译者ID) 校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](http://linux.cn/) 荣誉推出
|
||||
|
||||
[1]:http://autotest.github.io/
|
||||
[2]:https://github.com/autotest/autotest/wiki/WhitePaper
|
||||
[3]:http://events.linuxfoundation.org/sites/events/files/slides/Shuah_Khan_dma_map_error.pdf
|
||||
[4]:http://www.linuxjournal.com/content/july-2013-linux-kernel-news
|
||||
@ -1,90 +0,0 @@
|
||||
Linux Kernel Testing and Debugging
|
||||
================================================================================
|
||||
### Linux PM Sub-system Testing in Simulation Mode ###
|
||||
|
||||
The Linux PM sub-system provides five PM test modes to test hibernation in a simulated mode. These modes allow exercising the hibernation code in various layers of the kernel without actually suspending the system. This is useful when there is a concern that suspend might not work on a specific platform and help detect errors in a simulation similar to simulating flying a plane, so to speak.
|
||||
|
||||
freezer - test the freezing of processes
|
||||
|
||||
echo freezer > /sys/power/pm_test
|
||||
echo platform > /sys/power/disk
|
||||
echo disk > /sys/power/state
|
||||
|
||||
devices - test the freezing of processes and suspending of devices
|
||||
|
||||
echo devices > /sys/power/pm_test
|
||||
echo platform > /sys/power/disk
|
||||
echo disk > /sys/power/state
|
||||
|
||||
platform - test the freezing of processes, suspending of devices and platform global control methods(*)
|
||||
|
||||
echo platform > /sys/power/pm_test
|
||||
echo platform > /sys/power/disk
|
||||
echo disk > /sys/power/state
|
||||
|
||||
processors - test the freezing of processes, suspending of devices, platform global control methods(*) and the disabling of non-boot CPUs
|
||||
|
||||
echo processors > /sys/power/pm_test
|
||||
echo platform > /sys/power/disk
|
||||
echo disk > /sys/power/state
|
||||
|
||||
core - test the freezing of processes, suspending of devices, platform global control methods, the disabling of non-boot CPUs and suspending of platform/system devices. Note: this mode is tested on ACPI systems.
|
||||
|
||||
echo core > /sys/power/pm_test
|
||||
echo platform > /sys/power/disk
|
||||
echo disk > /sys/power/state
|
||||
|
||||
### Linux PM Sub-system Trace Events ###
|
||||
|
||||
PM sub-system supports several tracepoints and trace events that can be enabled to trigger during run-time. I will give an overview on how to enable couple of these trace events and where to find the trace information they generate:
|
||||
|
||||
Enabling PM events at run-time:
|
||||
|
||||
cd /sys/kernel/debug/tracing/events/power
|
||||
echo 1 > cpu_frequency/enable
|
||||
cat /sys/kernel/debug/tracing/set_event
|
||||
less /sys/kernel/debug/tracing/trace
|
||||
|
||||
Enabling events at boot-time kernel trace parameter with a kernel boot option:
|
||||
|
||||
trace_event=cpu_frequency
|
||||
|
||||
For more information on Linux PM testing, please consult the Documentation/power/basic-pm-debugging.txt and other documents in the same directory.
|
||||
|
||||
### git bisect ###
|
||||
|
||||
git bisect is an invaluable and powerful tool to isolate an offending commit. I will go over very basic git bisect steps.
|
||||
|
||||
This is how the process works:
|
||||
|
||||
git bisect start
|
||||
git bisect bad # Current version is bad
|
||||
git bisect good v3.14-rc6 # last good version
|
||||
|
||||
Once, one bad and one good version are specified, git bisect will start bisecting by pulling in commits between the good version and the bad. Once a set of commits are pulled in, compile the kernel, install, test, and tag the version good or bad. This process repeats until the selected commits are tested and tagged as good or bad. There can be several kernel versions to test. When the last version is tested, git bisect will flag a commit that is bad. The following useful git-bisect command can aid in using git-bisect process:
|
||||
|
||||
See step by step bisect progress
|
||||
|
||||
git bisect log
|
||||
|
||||
Reset git bisect can be used in case of mistakes in tagging, save git log output and replay prior to reset
|
||||
|
||||
git bisect reset
|
||||
|
||||
Replay a git-bisect log
|
||||
|
||||
git bisect replay git_log_output
|
||||
|
||||
git bisect can be run on a section of kernel source tree if the problem is clearly in that area. For example, when debugging a problem in radeon driver, running git bisect on drivers/drm/radeon will limit the scope of bisect to just the commits to drivers/drm/radeon driver.
|
||||
|
||||
Start git bisect on a section of a kernel tree
|
||||
|
||||
git bisect start drivers/drm/radeon
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: http://www.linuxjournal.com/content/linux-kernel-testing-and-debugging?page=0,4
|
||||
|
||||
译者：[译者ID](https://github.com/译者ID) 校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](http://linux.cn/) 荣誉推出
|
||||
@ -1,3 +1,4 @@
|
||||
[bazz2 last & largest one]
|
||||
Linux Kernel Testing and Debugging
|
||||
================================================================================
|
||||
### Linux Kernel Patch Testing ###
|
||||
@ -135,4 +136,4 @@ via: http://www.linuxjournal.com/content/linux-kernel-testing-and-debugging?page
|
||||
[16]:http://lwn.net/Kernel/LDD3/
|
||||
[17]:http://events.linuxfoundation.org/slides/lfcs2010_hiramatsu.pdf
|
||||
[18]:http://events.linuxfoundation.org/images/stories/slides/elc2013_porter.pdf
|
||||
[a]:http://www.linuxjournal.com/users/shuah-khan
|
||||
[a]:http://www.linuxjournal.com/users/shuah-khan
|
||||
|
||||
145
translated/tech/20140718 Linux Kernel Testing and Debugging 4.md
Normal file
145
translated/tech/20140718 Linux Kernel Testing and Debugging 4.md
Normal file
@ -0,0 +1,145 @@
|
||||
Linux 内核测试和调试 - 4
|
||||
================================================================================
|
||||
### 自动测试工具 ###
|
||||
|
||||
这里列出一些能满足不同需求的测试工具供你选择。本小节只是简单介绍个大概，并不提供详细操作指南。
|
||||
|
||||
#### [AuToTest][1] ####
|
||||
|
||||
> AuToTest 是一个全自动测试框架，存在的主要目的就是测试 Linux 内核，当然也可以用来测试其他东西，比如测试一块新硬件是否能稳定工作。AuToTest 是开源软件，以 GPL 方式授权，运行于 server-client 架构（即 C/S 架构）。你可以通过配置 server 端来对运行了 client 端的系统执行初始化、运行与监测工作，也可以自己在目标系统上让 client 运行起来。另外你可以为这个测试框架添加测试用例，详情请参考[AuToTest 白皮书][2]。
|
||||
|
||||
#### Linaro Automated Validation Architecture ####
|
||||
|
||||
> LAVA 自动测试框架用于自动安装于运行测试。举个例子：你在 LAVA 里面只需运行几个命令就可以跑 LTP（LCTT：Linux Test Project，中文是 Linux 测试计划，SGI发起并由IBM负责维护，目的是为开源社区提供测试套件来验证Linux的可靠性、健壮性和稳定性）。通过 LAVA 命令可以自动为你安装 LTP 所需要的所有依赖包，下载源码、编译编码、将 LTP 安装到某个独立的地方，方便卸载 LTP 时能移除所有二进制文件。安装好 LTP 后，运行 LAVA 命令时添加 'ltp' 选项就可以运行 LTP 测试任务了，它会将测试结果以文件方式保存下来，文件名包含测试名称、时间戳。这些测试结果可以留着供以后参考。这是个发现软件退化（如果软件退化了的话）的好方法。下面列出 LAVA 配合 LTP 使用的一些命令：
|
||||
|
||||
显示 LAVA 支持的测试列表：
|
||||
|
||||
lava-test list-tests
|
||||
|
||||
安装测试套件：
|
||||
|
||||
lava-test install ltp
|
||||
|
||||
运行测试：
|
||||
|
||||
lava-test run ltp
|
||||
|
||||
查看结果：
|
||||
|
||||
lava-test results show ltp-timestamp.0
|
||||
|
||||
卸载测试套件：
|
||||
|
||||
lava-test uninstall ltp
|
||||
|
||||
### 内核调试功能 ###
|
||||
|
||||
Linux 内核本身包含很多调试功能，比如 kmemcheck 和 kmemleak。
|
||||
|
||||
#### kmemcheck ####
|
||||
|
||||
> kmemcheck 是一个动态检查工具，可以检测出一些未被初始化的内存（LCTT：内核态使用这些内存可能会造成系统崩溃）并发出警告。它的功能与 Valgrind 类似，只是 Valgrind 运行在用户态，而 kmemchecke 运行在内核态。编译内核时加上 CONFIG_KMEMCHECK 选项打开 kmemcheck 调试功能。你可以阅读 Documentation/kmemcheck.txt 来学习如何配置使用这个功能，以及如何看懂调试结果。
|
||||
|
||||
#### kmemleak ####
|
||||
|
||||
> kmemleak 通过类似于垃圾收集器的功能来检测内核是否有内存泄漏问题。而 kmemleak 与垃圾收集器的不同之处在于前者不会释放孤儿目标（LCTT：不会再被使用的、应该被释放而没被释放的内存区域），而是将它们打印到 /sys/kernel/debug/kmemleak 文件中。用户态的 Valgrind 也有一个类似的功能，使用 --leak-check 选项可以检测并报错内存泄漏问题，但并不释放这个孤儿内存。编译内核时使用 CONFIG_DEBUG_KMEMLEAK 选项打开 kmemcleak 调试功能。阅读 Documentation/kmemleak.txt 来学习怎么使用这个工具并读懂调试结果。
|
||||
|
||||
### 内核调试接口 ###
|
||||
|
||||
Linux 内核通过配置选项、调试用的 API、接口和框架来支持动态或静态的调试。我们现在就好好学习学习这些牛逼的功能，从静态编译选项开始讲。
|
||||
|
||||
### 调试配置选项：静态编译 ###
|
||||
|
||||
大部分 Linux 内核以及内核模块都包含调试选项，你只要在编译内核或内核模块的时候添加这个静态调试选项，程序运行时后就会产生调试信息，并记录在 dmesg 缓存中。
|
||||
|
||||
### 调试的 API ###
|
||||
|
||||
调试 API 的一个很好的例子是 DMA-debug，用来调试驱动是否错误使用了 DMA 提供的 API。它会跟踪每个设备的映射关系，检测程序有没有试图为一些根本不存在的映射执行“取消映射”操作，检测代码建立 DMA 映射后可能产生的“映射丢失”的错误。内核配置选项 CONFIG_HAVE_DMA_APT_DEBUG 和 CONFIG_DMA_API_DEBUG 可以为内核提供这个功能。其中，CONFIG_DMA_API_DEBUG 选项启用后，内核调用 DMA 的 API 的同时也会调用 Debug-dma 接口。举例来说，当一个驱动调用 dma_map_page() 函数来映射一个 DMA 缓存时，dma_map_page() 会调用debug_dma_map_page() 函数来跟踪这个缓存，直到驱动调用 dma_unmap_page() 来取消映射。详细内容请参考[使用 DMA 调试 API 检测潜在的数据污染和内存泄漏问题][3]。
|
||||
|
||||
### 动态调试 ###
|
||||
|
||||
动态调试功能就是你可以决定在程序运行过程中是否要 pr_debug(), dev_dbg(), print_hex_dump_debug(), print_hex_dump_bytes() 这些函数正常运行起来。什么意思？当程序运行过程中出现错误时，你可以指定程序打印有针对性的、详细的调试信息。这功能牛逼极了，我们不再需要为了添加调试代码定位一个问题，而重新编译安装内核。你可以指定 CONDIF_DYNAMIC_DEBUG 选项打开动态调试功能，然后通过 /sys/kernel/debug/dynamic_debug/control 接口指定要打印哪些调试日志。下面分别列出代码级别和模块级别打印日志的操作方法：
|
||||
|
||||
让 kernel/power/suspend.c 源码第340行的 pr_debug() 函数打印日志：
|
||||
|
||||
echo 'file suspend.c line 340 +p' > /sys/kernel/debug/dynamic_debug/control
|
||||
|
||||
让内核模块在加载过程中打开动态调试功能：
|
||||
|
||||
> 使用 modprobe 命令加在模块时加上 dyndbg='plmft' 选项。
|
||||
|
||||
让内核模块的动态调试功能在重启后依然有效：
|
||||
|
||||
> 编辑 /etc/modprobe.d/modname.conf 文件（没有这个文件就创建一个），添加 dyndbg='plmft' 选项。然而对于哪些通过 initramfs 加载的驱动来说，这个配置基本无效（LCTT：免费奉送点比较高级的知识哈。系统启动时，需要先让 initramfs 挂载一个虚拟的文件系统，然后再挂载启动盘上的真实文件系统。这个虚拟文件系统里面的文件是 initramfs 自己提供的，也就是说你在真实的文件系统下面配置了 /etc/modprobe.d/modname.conf 这个文件，initramfs 是压根不去理会的。站在内核驱动的角度看：如果内核驱动在 initramfs 过程中被加载到内核，这个驱动读取到的 /etc/modprobe.d/modname.conf 是 initramfs 提供的，而不是你编辑的那个。所以会有上述“写了配置文件后重启依然无效”的结论）。对于这种刁民，呃，刁驱动，我们需要修改 grub 配置文件，在 kernel 那一行添加 module.dyndbg='plmft' 参数，这样你的驱动就可以开机启动动态调试功能了。
|
||||
|
||||
想打印更详细的调试信息，可以使用 dynamic_debug.verbose=1 选项。参考 Documentation/dynamic-debug-howto.txt 文件获取更多信息。
|
||||
|
||||
### 设置追踪点 ###
|
||||
|
||||
到目前为止，我们介绍了多种动态和静态调试方法。静态调试选项和静态调试钩子函数（比如 DMA Debug API）需要的编译过程打开或关闭，导致了一个难过的事实：需要重新编译安装内核。而动态编译功能省去了“重新编译”这件麻烦事，但是也有不足的地方，就是调试代码引入了条件变量，用于判断是否打印调试信息。这种方法可以让你在程序运行时决定是否打印日志，但需要执行额外的判断过程。“追踪点”代码只会在程序运行过程中使用“追踪点”功能才会被触发。也就是说，“追踪点”代码与上述说的两种方法都不一样。当用不到它时，它不会运行（LCTT：动态调试的话，代码每次都需要查看下变量，然后判断是否需要打印日志；而“追踪点”貌似利用某种触发机制，不需要每次都去查看变量）。当你需要用到它时，程序的代码会把“追踪点”代码包含进去。它不会添加任何条件变量来增加系统的运行负担。
|
||||
|
||||
详细信息请参考[布置追踪代码的小技巧][4]。
|
||||
|
||||
### “追踪点”的原理 ###
|
||||
|
||||
追踪点使用“跳跃标签”，这是一种使用分支跳转的编码修正（code modification）技术。
|
||||
|
||||
当关闭追踪点的时候，其伪代码看起来时这样的：
|
||||
|
||||
[ code1 ]
|
||||
nop
|
||||
back:
|
||||
[ code2 ]
|
||||
return;
|
||||
tracepoint:
|
||||
[ tracepoint code ]
|
||||
jmp back;
|
||||
|
||||
当打开追踪点的时候，其伪代码看起来时这样的：（注意追踪点代码出现的位置）
|
||||
|
||||
[ code1 ]
|
||||
jmp tracepoint
|
||||
back:
|
||||
[ code2 ]
|
||||
return;
|
||||
tracepoint:
|
||||
[ tracepoint code ]
|
||||
jmp back;
|
||||
|
||||
（LCTT：咳咳，解释解释上面两段伪代码吧，能看懂的大神请忽略这段注释。不使用追踪点时，代码运行过程是：code1->code2->return结束；使用追踪点时，代码运行过程是：code1->跳到tracepoint code执行调试代码->跳回code2->return结束。两段代码的唯一区别就是第二行，前者为 nop（不做任何操作），后者为 jmp tracepoint （跳到调试代码）。）
|
||||
|
||||
### Linux 电源管理子系统的测试 ###
|
||||
|
||||
使用静态调试、动态调试和追踪调试技术，我们来跑一下磁盘的电源管理测试。当系统被挂起时，内核会为磁盘创建一个休眠镜像，使磁盘进入休眠模式，当系统重新被唤醒时，内核又利用这个休眠镜像重新唤醒磁盘。
|
||||
|
||||
设置挂起设备与唤醒设备需要的时间：
|
||||
|
||||
echo 1 > /sys/power/pm_print_times
|
||||
|
||||
以 reboot 模式挂起磁盘：
|
||||
|
||||
echo reboot > /sys/power/disk
|
||||
echo disk > /sys/power/state
|
||||
|
||||
以 shutdown 模式挂起磁盘 —— 与 reboot 模式一样，只是重新唤醒磁盘的话还需要电源提供。
|
||||
|
||||
echo shutdown > /sys/power/disk
|
||||
echo disk > /sys/power/state
|
||||
|
||||
以 platform 模式挂起磁盘 —— 能测试更多内容，比如 BIOS 挂起和唤醒，会涉及到 ACPI 功能。我们推荐你使用这种方式，把 BIOS 也拉下水陪你玩挂起和唤醒游戏。
|
||||
|
||||
echo platform > /sys/power/disk
|
||||
echo disk > /sys/power/state
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via:http://www.linuxjournal.com/content/linux-kernel-testing-and-debugging?page=0,3
|
||||
|
||||
译者：[bazz2](https://github.com/bazz2) 校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](http://linux.cn/) 荣誉推出
|
||||
|
||||
[1]:http://autotest.github.io/
|
||||
[2]:https://github.com/autotest/autotest/wiki/WhitePaper
|
||||
[3]:http://events.linuxfoundation.org/sites/events/files/slides/Shuah_Khan_dma_map_error.pdf
|
||||
[4]:http://www.linuxjournal.com/content/july-2013-linux-kernel-news
|
||||
@ -0,0 +1,90 @@
|
||||
Linux 内核测试和调试 - 5
|
||||
================================================================================
|
||||
### 仿真环境下进行 Linux 电源管理子系统测试 ###
|
||||
|
||||
Linux 电源管理子系统在仿真环境下提供5种测试方式。这些方式仅仅在内核各层之间运行休眠的代码而不是真正的让系统进入休眠状态。有些平台不能挂起系统，比如说我们需要模拟飞机的飞行环境，这时候使用这种仿真环境就非常有用处了。
|
||||
|
||||
freezer - 测试停掉处理器：
|
||||
|
||||
echo freezer > /sys/power/pm_test
|
||||
echo platform > /sys/power/disk
|
||||
echo disk > /sys/power/state
|
||||
|
||||
devices - 测试停掉处理器以及挂起设备：
|
||||
|
||||
echo devices > /sys/power/pm_test
|
||||
echo platform > /sys/power/disk
|
||||
echo disk > /sys/power/state
|
||||
|
||||
platform - 测试停掉处理器、挂起设备以及平台全局控制方法(*)
|
||||
|
||||
echo platform > /sys/power/pm_test
|
||||
echo platform > /sys/power/disk
|
||||
echo disk > /sys/power/state
|
||||
|
||||
processors - 测试停掉处理器、挂起设备和平台全局控制方法(*)，以及关闭未启动的 CPU。
|
||||
|
||||
echo processors > /sys/power/pm_test
|
||||
echo platform > /sys/power/disk
|
||||
echo disk > /sys/power/state
|
||||
|
||||
core - 测试停掉处理器、挂起设备和平台全局控制方法(*)，关闭未启动的 CPU，以及挂起平台或系统的设备。注意：这个测试模式运行在 ACPI 系统。
|
||||
|
||||
echo core > /sys/power/pm_test
|
||||
echo platform > /sys/power/disk
|
||||
echo disk > /sys/power/state
|
||||
|
||||
### Linux 电源管理子系统追踪事件 ###
|
||||
|
||||
电源管理子系统在运行过程中支持多种追踪点和追踪事件。我将对如何使用这些追踪时间以及如何找到追踪信息作一个简单的介绍：
|
||||
|
||||
在运行时开启电源管理事件：
|
||||
|
||||
cd /sys/kernel/debug/tracing/events/power
|
||||
echo 1 > cpu_frequency/enable
|
||||
cat /sys/kernel/debug/tracing/set_event
|
||||
less /sys/kernel/debug/tracing/trace
|
||||
|
||||
为内核启动的命令添加一个参数：
|
||||
|
||||
trace_event=cpu_frequency
|
||||
|
||||
更多信息查看 Documentation/power/basic-pm-debugging.txt 以及同目录下其他的文档。
|
||||
|
||||
### git bisect 命令 ###
|
||||
|
||||
git bisect 是一个非常有用非常强大的工具，用于将 git 上的一个 commit 分离出来。我简单过一遍它的用法。
|
||||
|
||||
下面是 git bisect 的用法：
|
||||
|
||||
git bisect start
|
||||
git bisect bad # 当前版本是坏的
|
||||
git bisect good v3.14-rc6 # 上个版本是好的
|
||||
|
||||
一旦指定好好的版本和坏的版本，git bisect 就会开始把好坏两个版本之间的所有 commit 对半分，并将其中的一半提交 pull 下来。然后重新编译安装测试内核，并标记这个内核是好是坏。重复这个过程，知道某个你选好的 commit 被标记被好或者坏。我们可能需要测试多个内核版本，测到最后一个版本时，git bisect 会将一个 commit 标记为坏。下面的命令可以在 git bisect 分析过程中起到帮助作用：
|
||||
|
||||
查看 bisect 操作的过程：
|
||||
|
||||
git bisect log
|
||||
|
||||
重置 git bisect，标记错误时可以用到，保存 git log 的输出，重新操作上一次 bisect 的步骤：
|
||||
|
||||
git bisect reset
|
||||
|
||||
重放 git bisect 操作过程：
|
||||
|
||||
git bisect replay git_log_output
|
||||
|
||||
如果一个问题很清楚是在某个区域内，git bisect 命令可以定位到一个具体的内核源码树枝干上。举个例子，在调试一个镭龙显卡驱动的问题时，为 git bisect 指定 drivers/drm/radeon 参数，可以让 git bisect 只检索对 drivers/drm/radeon 里面的文件有修改的 commit。
|
||||
|
||||
让 git bisect 只检索内核树的某个枝干：
|
||||
|
||||
git bisect start drivers/drm/radeon
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: http://www.linuxjournal.com/content/linux-kernel-testing-and-debugging?page=0,4
|
||||
|
||||
译者：[bazz2](https://github.com/bazz2) 校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](http://linux.cn/) 荣誉推出
|
||||
Loading…
Reference in New Issue
Block a user