From: Bela Lubkin <belal@sco.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. > 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<
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.
Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.
Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.
We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.
Click here to add your comments
Don't miss responses! Subscribe to Comments by RSS or by Email
Click here to add your comments
If you want a picture to show with your comment, go get a Gravatar