How to check the kernel for kernel panic?

Question

I am testing the Linux kernel on an embedded device and would like to find situations / scenarios in which the Linux kernel gives out panic.

Can you suggest several testing steps (manually or with automatic code) to create panic in the kernel?

Answer 1

There are many tools you can use to try and crash your machine:

crashme is trying to execute random code; this is useful for testing process lifecycle code.

fsx is a tool that makes intensive use of file system code; This is useful for testing drivers, locking, and file system code.

The Linux testing project aims to create a large repository of sound tests; it may not be designed using failure systems in particular, but it can greatly help you and your team keep everything that was planned. (Note that LTP is not uppercase - the kernel community does not see their tests as something important - but the LTP team is very difficult to describe what the kernel does and does not.)

If your device is connected to the network, you can start nmap using various scan options: -sV --version-all will try to find the versions of all running services (this can be stressful), -O --osscan-guess will try to determine the operating system, throwing strange network packets on the machine and guessing the answers, what is the result.

The nessus scan tool also performs version identification of running services; it may or may not offer any improvements over nmap.

You can also transfer your device to users; they figure out the craziest things related to software, they find bugs that you would not even think of looking for. :)

Answer 2

You can try the following key combination

Sysrq + c

or

echo c> / proc / sysrq-trigger

Answer 3

Crashme is known to detect unknown kernel panic situations, but it should be run in a powerful way that creates many exceptions to the signals processed in the process and various conditions for exiting the process.

The main goal of the posts created by Crashme is to determine if interesting enough things are happening that indicate potential effectiveness. For example, if the mprotect call mprotect necessary to allow the memory allocated using malloc to be executed as instructions, and if you do not have mprotect included in the source code crashme.c for your platform, then Crashme is impotent.

X64-based operating systems seem to tend to disable execution for data segments. I recently updated crashme.c at http://crashme.codeplex.com/ to use mprotect in the case of __APPLE__ and tested it on a MacBook Pro MAC OS X Lion. This is Crashme's first major update since 1994. Expect Centos and Freebsd support to be updated soon.