The ability to capture system dumps when a system or kernel panic occurs is critical to the root cause analysis process. To capture these dumps for Red Hat Enterprise Linux 4 on the s390 platform, under VM, there are a couple of options. The following steps take you through the process of setting up a DASD dump device.

Note: For the purpose of this article we will use /dev/dasdb as our DASD device, dasdbp1 as our partition. This device is assigned as device 0.0.0101 to the guest image. You should substitute these as your needs dictate.

Setup:

First, login into your guest (via ssh or telnet) and review your defined DASD.

$ cat /proc/dasd/devices
0.0.0100(ECKD) at ( 94:     0) is dasda       : active at blocksize: 4096, 601020 blocks, 2347 MB
0.0.0101(ECKD) at ( 94:     4) is dasdb       : active at blocksize: 4096, 601020 blocks, 2347 MB

You will want to select a dasd device that is a little larger than the amount of defined memory. You will also want to be sure the device you choose is not in use as all data on the device will be lost. Once you have selected your device you will run the following command to layout the partition table on the device and define the dump device.

# fdasd -a /dev/dasdb
# zipl -d /dev/dasdb1
Warning: All information on partition '/dev/dasdb1' will be lost!
Do you want to continue creating a dump partition (y/n)? y

Test:

To test, we will force the system to panic. You will want a 3270 (I like x3270 for Linux) session as well as your ssh / telnet session. Login into the guest via your favorite 3270 client, do nothing else at this time - just watch .

From your ssh or telnet session, execute as root, the following command to panic the system.

# echo c > /proc/sysrq-trigger

Now in your 3270 window you should see that system has experienced a kernel panic. In your 3270 window execute the following cp commands to capture the resulting dump. Note, below

#cp store status
#cp i 101

This step will take a while, you will want to wait for the following results in your 3270 session window before continuing.

...disabled wait PSW...

IPL your guest and connect via ssh or telnet. You can validate your dump a couple of ways. First, directly on the device:

# zgetdump -i /dev/dasdb1
Dump device: /dev/dasdb1
Dump header information
Dump created on: Wed Sep 19 16:38:08 2007
Magic number:    0xa8190173618f23fd
Version number:  3
Header size:     4096
Page size:       4096
Dumped memory:   1073741824
Dumped pages:    262144
Real memory:     1073741824
cpu id:          0xff050afe20948000
System Arch:     s390x (ESAME)
Build Arch:      s390x (ESAME)
End of Dump header
Dump ended on:   Wed Sep 19 16:39:20 2007
Dump End Marker found: this dump is valid.

*Note your output should look similar to the above example, look for the dump is valid, and be sure to replace dasdb1 with your selected dump device.

Option two, and the method that will be required if you intend to send your dump to Red Hat for analysis or to another system for analysis.

# zgetdump /dev/dasdb1 > /some_directory/a_filename

*Where some_directory is a directory that has enough space to hold a large dump file and a_filename is any name you like.

References:

http://download.boulder.ibm.com/ibmdl/pub/software/dw/linux390/docu/l26bdt01.pdf