LED code 88 102 700 0c0

[shoux]

Hi expert !

The LED code of 88 102 700 0c0 was appear whilst running daily backup process. FYI, the system is just hang at the file with has size 3.1 GB. The machine has rebooted twice and still the error occurred. I realize that file system /var is increased to 100% and was found that the file vmcore.1 vmcore.2 is created automatically. So I decide to skip the backup and execute for other backup and it work. What is the meaning of this code? And is there any way to run the backup that was failed earlier? Is there any size limitation ?
I'm using tar command and oslevel is 4.3.0.0 RISC/6000
below is the errpt report.

-------------------------------------------------------------------------
LABEL: SYSDUMP_SYMP
IDENTIFIER: 3573A829

Date/Time: Sat Dec 28 01:14:14
Sequence Number: 72
Machine Id: 00052760A000
Node Id: SERVER1
Class: S
Type: UNKN
Resource Name: CMDCRASH

Description
SYSTEM DUMP

Probable Causes
UNEXPECTED SYSTEM HALT

User Causes
SYSTEM DUMP REQUESTED BY USER

Recommended Actions
PERFORM PROBLEM DETERMINATION PROCEDURES

Recommended Actions
PERFORM PROBLEM DETERMINATION PROCEDURES

Failure Causes
UNEXPECTED SYSTEM HALT

Recommended Actions
PERFORM PROBLEM DETERMINATION PROCEDURES

Detail Data
DUMP STATUS
LED:700
csa:00404eb0
vfindsid dc
vpageahead 23c
vreclaim 1cc
pfget 228
v_dpfget 23c
isync_dsis 60

Symptom Data
REPORTABLE
1
INTERNAL ERROR
: INTERNAL ERROR
1
SYMPTOM CODE
PIDS/5765C3403 LVLS/430 PCSS/SPI1 MS/700 FLDS/vfindsid VALU/c800000 FLDS/vpageah
ea VALU/23c
shoux

 

[Morsing]

The code only tells you it's a software error (102 700). You have do debug the dump to know what happened.

Cheers Henrik Morsing
IBM Certified AIX 4.3 Systems Administration

 

[MoshiachNow]

HI,

To debug the dump try the following process:

Analyzing system dump:

If the customer complains that his system had frozen with 888 on the display, check errpt for the entry like this:
C0AA5338 0614145601 U S SYSDUMP SYSTEM DUMP

This means that the system dump have occurred on 14 of June at 14:56.

Run the following command to verify the status of the last system dump:

# sysdumpdev -L

0453-039

Device name: /dev/hd6
Major device number: 10
Minor device number: 2
Size: 63952384 bytes
Date/Time: Thu Jun 14 14:43:11 CST 2001
Dump status: 0
dump completed successfully
Dump copy filename: /var/adm/ras/vmcore.0

Run the crash command on AIX 4.3.3/4.2.1 or kdb command on AIX5 in order to get a basic idea on the possible reasons of the system dump.
The crash subcommands (trace -k, thread -r, status 0) are used to provide a hint on the problem origin:

#cd /var/adm/ras
#crash vmcore.0

Using /unix as the default namelist file.

> trace -k
STACK TRACE:
0x2ff3b400 (excpt=edffff54:40000000:00001004:edffff54:00000106) (intpri=0)
IAR: .remove_e_list+38 (00032888): tweqi r7,0x0
LR: .e_block_thread+40c (00034424)
2ff3b010: .e_sleep_thread+4c (0003497c)
2ff3b060: .[nspdd]+4144 (016ba4e4)
2ff3b100: .[nspdd]+2de4 (016b9184)
2ff3b170: .[nspdd]+7e8 (016b6b88)
2ff3b1f0: .rdevioctl+140 (001b4344)
2ff3b260: .vnop_ioctl+1c (001c01d4)
2ff3b2a0: .vno_ioctl+144 (001d81d8)
2ff3b360: .common_ioctl+b0 (001e7894)
2ff3b3c0: .sys_call_ret+0 (00003a90)
IAR not in kernel segment.

> status 0

CPU TID TSLOT PID PSLOT STOPPED PROC_NAME
0 700f 112 6db0 109 yes pltDc

> thread -r

SLT ST TID PID CPUID POLICY PRI CPU EVENT PROCNAME FLAGS
2 r 205 204 0 FIFO 7f 78 wait
t_flags: sig_avail funnel kthread
3 r 307 306 1 FIFO 7f 78 wait
t_flags: sig_avail funnel kthread
4 r 409 408 2 FIFO 7f 78 wait
t_flags: sig_avail funnel kthread
5 r 50b 50a 3 FIFO 7f 78 wait
t_flags: sig_avail funnel kthread
112 r 700f 6db0 0 RR 40 0 pltDc
t_flags: local cdefer funnel


> proc -r

SLT ST PID PPID PGRP UID EUID TCNT NAME
2 a 204 0 0 0 0 1 wait
FLAGS: swapped_in no_swap fixed_pri kproc
3 a 306 0 0 0 0 1 wait
FLAGS: swapped_in no_swap fixed_pri kproc
55 a 37b8 2282 2282 200 200 1 X
FLAGS: swapped_in execed
112 a 7054 571a 25c8 200 200 1 expose
FLAGS: swapped_in no_swap fixed_pri ppnocldstop execed
122 a 7a14 1 744c 200 200 1 plateExp_dlg35
FLAGS: swapped_in orphanpgrp ppnocldstop execed

>q ;quits the crash command
=================================================================
In this case trace -k shows a problem with nspdd process, which is part of the TSP driver.
thread -r and status 0 both hint on the application process pltDc as responsible for the core dump (it's the last process that run).
"Long live king Moshiach !"
h

http://www.noahide.com/movement.htm

 

[JSiva]

1. Boot in Maintenance mode
2. Run lquerypv -h core 6b0 64 to determine which program/application creating the core dump.
3. Remove the core
4. Restart the system.

JSiva Om Maha Ganapathiye Namaga!

 

[MoshiachNow]

Unfortunately this is a system dump described here (vmcore.x),not the application dump.
The system dumps can NOT be analysed using "lquerypv -h core 6b0 64 " . "Long live king Moshiach !"
h

http://www.noahide.com/movement.htm

 

[JSiva]

Sorry and Thank you "levw". I was really not aware of it till now !

Thanks

JSiva Om Maha Ganapathiye Namaga!

 

[JSiva]

Sorry and Thank you "levw". I was really not aware of it till this morning!

Thanks

JSiva Om Maha Ganapathiye Namaga!

 

[MoshiachNow]

Welcome,

CAn also refer to :

http://www-1.ibm.com/support/docvie...p%22&uid=aix1a28c72fdc59c091d85256c520075a8d2

and

http://www-1.ibm.com/support/docvie...p%22&uid=aix1951ec39801f6b61d852568160069ff32

"Long live king Moshiach !"
h

http://www.noahide.com/movement.htm

 

[stritzgi]

In the crash output from above

> trace -k
STACK TRACE:
0x2ff3b400 (excpt=edffff54:40000000:00001004:edffff54:00000106) (intpri=0)
IAR: .remove_e_list+38 (00032888): tweqi r7,0x0

The "tweqi" instruction is what took the system down, The "t*" instructions are traps that will crash the system so the system got to somewhere that it could not deal with.

Send it off to IBM