Generally, there are many ways in which you can test the Linux kernel, but we will concentrate on the following four approaches:
1.Using a test version of the kernel for normal work.
2.Running special test suites, like LTP, on the new kernel.
3.Doing unusual things with the new kernel installed.
4.Measuring the system performance with the new kernel installed.
Of course, all of them can be used within one combined test procedure, so they can be regarded as different phases of the testing process.
2.1 Phase One
The first phase of kernel testing is simple: we try to boot the kernel and use it for normal work.
(1) Boot the kernel with the init=/bin/bash command line argument, which makes it start only one bash process. From there you can check if the filesystems are mounted and unmounted properly and you can test some more complex kernel functions, like the suspend to disk or to RAM, in the minimal configuration.
(2) Next, it is advisable to start the system in runlevel 2.
network and x serve. Check if the network interfaces work and try to run x server manually to make sure that it does not crash.
(3) Finally, you can boot the system into the runlevel 5(fully function) or level 3(fully function without x).
2.2 Phase Two(Auto test)
tool: autotest (http://test.kernel.org/autotest/)
some test tools for linux. http://ltp.sourceforge.net/tooltable.php
2.3 Phase Three
Do stupid things that nobody sane will do during the normal work.
Example, unplugging adn replugging USB devices.
2.4 Measuring performance
time-try to build some benchmark.
stability-change kernel (compare apples to apples).
2.5 What exactly are we looking for?
you can find some examples of messages that are related to kernel problems. Usually, such messages appear on the system console, but sometimes (eg. when the problem is not sufficiently serious to make the kernel crash immediately) you can also see them in the logs.
where to find the message ?
eg:
(1) console
(2) /sys/kernel/debug/memleak(if the kernel memory leak detector is used.)
2.6 Binary drivers and distribution kernels
sometimes you have no choice (eg. new AMD/ATI graphics adapters are not supported by any Open Source driver known to us).
You can check whether or not the kernel was tainted (means that the source of possible problems may be unrelated to the kernel code) when the problem occurred by looking at the corresponding error message.
If can you see something similar to the following line:
EIP: 0060:[<c046c7c3>] Tainted: P VLI(the word Tainted is crucial here), the kernel was tainted
Distribution kernels are meant to be supported by their distributors rather by the kernel developers, so the problems in these kernels should be reported to the distributors in the first place (usually, the distributor will contact the kernel developers anyway if that is necessary)
references:
https://linux.cn/article-3684-1.html
http://elinux.org/Test_Systems
http://kernelnewbies.org/Linux_Kernel_Tester%27s_Guide_Chapter2