testcases/kdump/README

   1 KDUMP TESTS AUTOMATION SUITE
   2 ----------------------------
   3
   4 The kdump test automation suite helps run the kdump tests and report
   5 results.  The testscripts cycle through a series of crash
   6 scenarios. Each test cycle does the following:
   7
   8 1.  Sets up a crash scenario.
   9 2.  Forces a crash.
  10 3.  Kdump kernel boots and saves a vmcore.
  11 4.  System reboots to 1st kernel.
  12 5.  vmcore is validated and results are saved.
  13 6.  After a 1 to 2 minute delay, the next crash scenario is setup and
  14     run.
  15
  16 The scripts make use of the crasher module for basic testing of kdump
  17 and the new Linux Kernel Dump Test Module (LKDTM) for more involved
  18 testing. LKDTM makes use of the kprobes infrastructure for inserting
  19 crashpoints into the kernel at run-time. Thus the kernel need not be
  20 patched and rebuilt.This script also tests kdump dumping on different
  21 destinations like ext3, raw and network dump.
  22
  23 KDUMP TEST INSTRUCTION
  24 ----------------------
  25
  26 Follow the steps to setup kdump test automation suite.
  27
  28 The tests are written for SuSE Linux Enterprise Server 10 (and onward
  29 releases), OpenSUSE, Fedora, Debian, as well as RedHat Enterprise Linux
  30 5. Since KDUMP is supported by the above mentioned distro's the tests
  31 were written and tested on them. Contribution towards supporting more
  32 distributions are welcome.
  33
  34 1. Install these additional packages:
  35
  36 For 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
  44 For 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
  52 2.  Make sure the partition where the tests are running has space for
  53 the tests results and one vmcore file (size of physical memory).
  54
  55 3. Modify configuration file runkdump.conf or copy a existing one from
  56 sample/.
  57
  58 4.  Run "make". Carefully check for any errors.
  59
  60 Few 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
  64 reboots. 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
  66 from 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
  70 happens, you'll need to manually reset the system so it reboots back to
  71 the 1st kernel and continues on to the next test. For this reason, it's
  72 best to monitor the tests from a console. If possible, setup a serial
  73 console (not a must, any type of console setup will do). If using
  74 minicom, enable saving of kernel messages displayed on minicom into a
  75 file, by pressing ctrl+a+l on the console. Else, when it is observed
  76 that the kdump kernel has failed to boot, manually copy the boot message
  77 into 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
  81 directory shows where you are in the test run. When the "Test run
  82 complete" entry appears in that file, you're done. Verbose log can be
  83 found at /tmp/kdump-<date>.log.
  84
  85 * The test machine would be unavailabe for any other work during the
  86 period of the test run.
  87
  88 * System may hang if incorrect partition information is provided for
  89 dumping, like specifying a partition which does not exist, specifying a
  90 parition label which does not exist. This is not ltp kdump bug.