1KDUMP TESTS AUTOMATION SUITE 2---------------------------- 3 4The kdump test automation suite helps run the kdump tests and report 5results. The testscripts cycle through a series of crash 6scenarios. Each test cycle does the following: 7 81. Sets up a crash scenario. 92. Forces a crash. 103. Kdump kernel boots and saves a vmcore. 114. System reboots to 1st kernel. 125. vmcore is validated and results are saved. 136. After a 1 to 2 minute delay, the next crash scenario is setup and 14 run. 15 16The scripts make use of the crasher module for basic testing of kdump 17and the new Linux Kernel Dump Test Module (LKDTM) for more involved 18testing. LKDTM makes use of the kprobes infrastructure for inserting 19crashpoints into the kernel at run-time. Thus the kernel need not be 20patched and rebuilt.This script also tests kdump dumping on different 21destinations like ext3, raw and network dump. 22 23KDUMP TEST INSTRUCTION 24---------------------- 25 26Follow the steps to setup kdump test automation suite. 27 28The tests are written for SuSE Linux Enterprise Server 10 (and onward 29releases), OpenSUSE, Fedora, Debian, as well as RedHat Enterprise Linux 305. Since KDUMP is supported by the above mentioned distro's the tests 31were written and tested on them. Contribution towards supporting more 32distributions are welcome. 33 341. Install these additional packages: 35 36For SLES10 or OpenSUSE Distro : 37 38 * kernel-kdump 39 * kernel-source 40 * kexec-tools 41 * zlib-64bit-<xxx> (ppc64 only) 42 * expect (if dump to a network destination) 43 44For RHEL5 or Fedora distro : 45 46 * kexec-tools 47 * kernel-devel 48 * kernel-debuginfo rpm (if using crash to verify vmcore) 49 * kernel-kdump ( only for ppc64 ) 50 * expect (if dump to a network destination) 51 522. Make sure the partition where the tests are running has space for 53the tests results and one vmcore file (size of physical memory). 54 553. Modify configuration file runkdump.conf or copy a existing one from 56sample/. 57 584. Run "runkdump.sh". Carefully check for any errors. 59 60Few Important points to remember: 61 62* If you need to stop the tests before all tests have run, run "crontab 63-r" and "killall runkdump.sh" within 1 minute after the 1st kernel 64reboots. Then, if you'd like to carry on tests from the point on, run 65"crontab kdump.cron", and "./runkdump.sh". If you'd like to start tests 66from the beginning, modify the configuration file, and set 67"REBOOT=0". Then, "./runkdump.sh" 68 69* A failure is likely to occur when booting the kdump kernel. If this 70happens, you'll need to manually reset the system so it reboots back to 71the 1st kernel and continues on to the next test. For this reason, it's 72best to monitor the tests from a console. If possible, setup a serial 73console (not a must, any type of console setup will do). If using 74minicom, enable saving of kernel messages displayed on minicom into a 75file, by pressing ctrl+a+l on the console. Else, when it is observed 76that the kdump kernel has failed to boot, manually copy the boot message 77into a file to enable the debugging the cause of the hang. 78 79* The results are saved in 80<kdump-test-dir>/log/<hostname>.<date-time>. The "status" file in that 81directory shows where you are in the test run. When the "Test run 82complete" entry appears in that file, you're done. Verbose log can be 83found at /tmp/kdump.log. 84 85* The test machine would be unavailable for any other work during the 86period of the test run. 87 88* System may hang if incorrect partition information is provided for 89dumping, like specifying a partition which does not exist, specifying a 90partition label which does not exist. This is not ltp kdump bug. 91