CODEWITHSUNDEEP
linuxlinux-kernellinux-device-driverembedded-linux
Ankur Agarwal
Ankur Agarwal

Reputation: 24748

How to test the kernel for kernel panics?

I am testing the Linux Kernel on an embedded device and would like to find situations / scenarios in which Linux Kernel would issue panics.

Can you suggest some test steps (manual or code automated) to create Kernel panics?

Upvotes: 8

Views: 10638

Answers (3)

adobriyan
adobriyan

Reputation: 2662

You can try following key combination

SysRq + c

or

echo c >/proc/sysrq-trigger

Upvotes: 9

George Carrette
George Carrette

Reputation: 721

Crashme has been known to find unknown kernel panic situations, but it must be run in a potent way that creates a variety of signal exceptions handled within the process and a variety of process exit conditions.

The main purpose of the messages generated by Crashme is to determine if sufficiently interesting things are happening to indicate possible potency. For example, if the mprotect call is needed to allow memory allocated with malloc to be executed as instructions, and if you don't have the mprotect enabled in the source code crashme.c for your platform, then Crashme is impotent.

It seems that operating systems on x64 architectures tend to have execution turned off for data segments. Recently I have updated the crashme.c on http://crashme.codeplex.com/ to use mprotect in case of __APPLE__ and tested it on a MacBook Pro running MAC OS X Lion. This is the first serious update to Crashme since 1994. Expect to see updated Centos and Freebsd support soon.

Upvotes: 1

sarnold
sarnold

Reputation: 104020

There's a variety of tools that you can use to try to crash your machine:

crashme tries to execute random code; this is good for testing process lifecycle code.

fsx is a tool to try to exercise the filesystem code extensively; it's good for testing drivers, block io and filesystem code.

The Linux Test Project aims to create a large repository of kernel test cases; it might not be designed with crashing systems in particular, but it may go a long way towards helping you and your team keep everything working as planned. (Note that the LTP isn't proscriptive -- the kernel community doesn't treat their tests as anything important -- but the LTP team tries very hard to be descriptive about what the kernel does and doesn't do.)

If your device is network-connected, you can run nmap against it, using a variety of scanning options: -sV --version-all will try to find versions of all services running (this can be stressful), -O --osscan-guess will try to determine the operating system by throwing strange network packets at the machine and guessing by responses what the output is.

The nessus scanning tool also does version identification of running services; it may or may not offer any improvements over nmap, though.

You can also hand your device to users; they figure out the craziest things to do with software, they'll spot bugs you'd never even think to look for. :)

Upvotes: 11

Related Questions