TOC dump fails on D class server - (newbie question)

[Scott Lindstrom_2]

I have a D class machine that I am attempting to produce a TOC crashdump (so I can learn dump analysis).

The dump process runs for a couple of minutes then dies with the following messages:
***Dumping : 0% complete (32 of 2 mb) (device)
***Dumping : 9% complete (32 of 2 mb) (device)
ERROR: can't write to device using firmware.
ERROR: write error on device. Dump aborted.

The machine has 256mb of memory. Running lvlnboot -v shows (in part):

Dump: lvol2 on: /dev/dsk/c0t5d0, 0
Dump: lvdump on: /dev/dsk/c0t5d0, 1

lvdisplay shows lvol2 as 512mb, and lvdump as 256mb. Permission is read/write, Allocation is strict/contiguous, Bad block is off.

Originally only lvol2 was setup for dumps, but based on the info the Crashdump chapter of the recently posted Software Recovery Handbook, I added lvdump just in case that would solve the problem. It didn't.

Any ideas would be appreciated.

[Patrick Wessel]

Scott,
This is no a usual message on a D-Class.
What kind of disc is your dump-device. Is it maybe a 4GB Seagate X-Wing?

[Joaquin Gil de Vergara]

check first of all if disk is well

dd if=dev/dsk/c0t5d0 of=dev/null bs=1024

[Scott Lindstrom_2]

Patrick-

ioscan shows the disk as SEAGATE ST34572WC. It understand it is 4.3gb. (Not sure how to know if it's X-Wing).

Joaquin -

The dd command runs for a few minutes then outputs:
4194157+0 records in
4194157+0 records out

Scott

[Patrick Wessel]

Scott,
I tried to find a gentle way to tell you the truth, but couldn't find one???
Your disc is one of two possible that may cause problems with the dump. This is caused by timing issues with the SCSI protocol chip on the disc. I never heard of a final fix for this problem, that means, if you have the possibility to dump to another disc (of another type) you should do this as a workaround

[Scott Lindstrom_1]

Patrick -

Let me see if I can allocate a second disk and see what happens.

Thanks,
Scott

[Scott Lindstrom_2]

I went through the process of using crashconf to create a dump volume on the second disk drive (vg01). Somewhere along the way I read about selective vs full dumps, so when I started the TOC dump, I indicated afterwards that I wanted a full dump.

It worked with no problems at all.

Being curious whether the new volume fixed the problem, or the full dump fixed the problem, I tried a selective dump again. It failed with the original problem.

So I guess I'll stick to a full dump if I ever see this problem in the future!

Scott

[Tobias Fleischer]

Hi Scott,

maybe you should update the code that is responsible for processing the dump. On HP-UX 11.00 it is patch PHKL_22926.

Regards
Tobias