A.P. Lawrence

dump image corrupt

If this isn't exactly what you wanted, please try our Search (there's a LOT of techy and non-techy stuff here about Linux, Unix, Mac OS X and just computers in general!):

From: Bela Lubkin <belal@caldera.com>
Subject: Re: 'crash' utility failure
Date: Mon, 14 Jan 2002 10:04:56 GMT References: <00a001c19be0$a6975640$7001a8c0@estacion3>

Fernando Ronci wrote:

> What can be wrong with a dump image after a kernel panic (0x0000000E) of OSR
> 5.0.0 that it cannot be read by the 'crash' utility?
> I saved the image in /usr/tmp/dump.1201 and when I issue:
> crash -d /usr/tmp/dump.1201
> 
> I get:
> dumpfile = /usr/tmp/dump.1201, namelist = /unix, outfile = stdout
> Read error on page table entry at 0xfc60ff0
> 
> What does the "Read error on page table entry at 0xfc60ff0" error mean?

It means that the dump image is corrupt, for crash's purposes.

During a panic, the system is in an unstable state (by definition).  Not
all panics produce clean, readable dumps.

It's also possible that it was a clean dump, but you corrupted it when
you saved it.

Lone-Tar Backup and Disaster Recovery
for Linux and Unix

> BTW, I picked the dump image from /dev/swap with the command:
> dd if=/dev/swap of=/usr/tmp/dump.1201 bs=1024 count=`expr \`memsize
> /dev/swap\` / 1024 + 1` as exemplified in TA # 105840. Swap and dump devices
> are the same.

Next time the system panics, go to single-user mode and immediately run:

  crash -d /dev/swap

If this works, you have a good dump image in /dev/swap; your copying
methodology is broken.

You should get the tools /etc/crash, /etc/sysdump, /etc/scodb from an
OSR506 system; and the sysdump(ADM), scodb(ADM) man pages.  The tools
are backwards-compatible.  /etc/sysdump can save a dump image, does a
better job than `dd`, and it merges together the kernel and dump so that
you don't have to worry about getting them out of sync.  The 5.0.6
version of crash has a number of improvements.  /etc/scodb is a
user-level version of the kernel debugger; it can give you a different
perspective on a crash dump.

> I need to know why my system began panicing at random intervals (about 3
> times a day) after a major hardware upgrade.
> I moved the old SCSI HD to a new motherboard with a PIII 900 MHz, new
> memory, new NIC, legacy ISA computone and legacy Adaptec card. After reading
> Tony's document at http://www.aplawrence.com/Unixart/trape.shtml
> I'm almost sure the culprit is either the memory or the new NIC driver (a
> very ordinary Encore PCI card), but 'crash' needs to be able to read the
> dump image to confirm that.

It's probably the memory (or possibly the CPU, if something is grossly
wrong, like the heat sink fan is broken).  There isn't really anything
to confirm if it's memory.

Even without being able to examine the crash dump, you should write down
the EIP addresses reported by each panic.  If they're all different,
it's some sort of flaky hardware problem like bad RAM or overheating
CPU.  If they're all the same, you can use various tools on the kernel
(crash; adb; nm) to translate the address to a symbolic label.  If the
label is inside the NIC driver or some other obvious place like that,
you'll know the cuplrit.

>Bela<

Enter your email address for automatic notification of new posts here
(be sure to whitelist 'feedburner.com' if you use spam filtering)

/Bofcusm/1399.html copyright 1997-2004 Bela Lubkin All Rights Reserved

Have you tried Searching this site?

Unix/Linux/Mac OS X support by phone, email or on-site: Support Rates

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more. We appreciate comments and article submissions.

Publishing your articles here