Yes Stan, a dump-to-disc was taken, analyzed by HP and the offending semaphores identified. An SR is wending it's way through HP as
we speak. The info from HP appears below. Any strings of x's indicate identifying info that was removed. (Hey! I don't want any 3rd party
software vendors taking me to task. The firms involved are well aware of what happened and are working on it.)
Come on people! Is Stan-the-Man Sieler the only one of you out there with knowledge of PEUTIL? HP played deaf and dumb about it
when I logged a call. (Maybe I just got the wrong person) Is HP3000-L *stumped*? Has no one used PEUTIL? And here I thought that
this list was the greatest repository of HP3000 knowledge world wide! <g>
Paul
On Thu, 3 Aug 2000 16:45:18 -0700, Stan Sieler wrote:
>Re:
>> PEUTIL.PUB.SYS caused a deadly embrace between two semaphore flags
>> on our system yesterday.
>> Has anyone had any similar experiences or any info on the proper
>> care and feeding of PEUTIL?
>
>Well, that's one reason why I always caution people about using AIF:PE :)
>
>Seriously, I haven't run into any such problem before.
>
>Did you take a dump and were the offending semaphores identified?
>
>
>Stan Sieler [log in to unmask]
>www.allegro.com/sieler/wanted/index.html www.allegro.com/sieler
FROM HP:
dump analysis
hang - dispatch queue is empty
xxxxxx VERSION: X.xx.xx (C.60.00 - 6.0)
I did a process_wait, and half of all processes are on a
CONTROL_BLOCK_WAIT....tracking it down, you come up with a
deadlock between the
semcl_pm_pcl semaphore and semcl_gufd semaphore.
nmdat > pin 57a;pm_ptree pin;tr,d,i
$57a (PEUTIL.PUB.SYS) #S1573
PC=a.0016570c enable_int+$2c
NM* 0) SP=41852d78 RP=a.002aab98
notify_dispatcher.block_current_process+$324
NM 1) SP=41852d78 RP=a.002ad03c notify_dispatcher+$264
NM 2) SP=41852cf8 RP=a.001943e4
sem_block.wait_for_resource+$1c4
NM 3) SP=41852bf8 RP=a.001945fc sem_block+$178
NM 4) SP=41852b38 RP=a.0016c9a4 joint_lock_path+$34
NM 5) SP=41852a38 RP=a.005c72c8 sm_close_fd+$254
NM 6) SP=418529f0 RP=a.005c894c sm_close+$48
NM 7) SP=418526f0 RP=a.005c88d0 ?sm_close+$8
export stub: a.00ad91fc extra_close+$90
NM 8) SP=41852670 RP=a.00ad9a38 lt_delete1+$210
NM 9) SP=418525f0 RP=a.00adc034 disarm_a_handler+$214
NM a) SP=41852530 RP=a.00adc1b4 disarm_a_pins_handlers+$118
NM b) SP=418524b0 RP=a.00adc304 disarm_all_pins_handlers+$7c
NM c) SP=418523f0 RP=a.00add8d4 pe_allow_not+$13c
NM d) SP=41852370 RP=a.00add784 ?pe_allow_not+$8
export stub: 39a4.00011d3c
NM e) SP=418522b0 RP=39a4.00011ce0
export stub: 39a4.000113a8
NM f) SP=41852270 RP=39a4.00013354
Can't unwind. Error reading a value from virtual memory.
nmdat > lev 4;dv psp-28,2
VIRT $d38.41852a10 $ 0000000a ca08fb14
nmdat > fv ca08fb14 'semaphore_rec'
RECORD
SEM_INFO_WORD :
SEM_STATE : 2
SEM_LOCK : 0
SEM_SPEC : 2
SEM_CLASS : 15 <-- semcl_gufd
SEM_OWNER : 6c4
SEM_SPIN_STATE_REC :
SPIN_SEM_STATE : 0
SPIN_SEM_LOCK : 0
SPIN_SEM_SPEC : 0
SPIN_SEM_CLASS : 0
SPIN_SEM_OWNER : 1
SEM_SPIN_OWNER_COUNT : 415
END
nmdat > pin 6c4;pm_ptree pin;tr,d,i
$6c4 (the 3rd party software shall remain nameless, lest I be sued.) #J1448
PC=a.0016570c enable_int+$2c
NM* 0) SP=4185c610 RP=a.002aab98
notify_dispatcher.block_current_process+$324
NM 1) SP=4185c610 RP=a.002ad03c notify_dispatcher+$264
NM 2) SP=4185c590 RP=a.001943e4
sem_block.wait_for_resource+$1c4
NM 3) SP=4185c490 RP=a.001945fc sem_block+$178
NM 4) SP=4185c3d0 RP=a.0016cebc aligned_joint_lock_path+$34
NM 5) SP=4185c2d0 RP=a.002774ec get_pcl+$8c
NM 6) SP=4185c288 RP=a.00530e38 delete_protectid_entry+$64
NM 7) SP=4185c1c8 RP=a.00568fe4 vsm_clean_up_file_user+$1a8
NM 8) SP=4185c0c8 RP=a.005c8568 sm_close_fd+$14f4
NM 9) SP=4185c008 RP=a.00c1e9ac tm_close_common+$1a68
NM a) SP=4185bd08 RP=a.00be6ef8 tm_ord_fix_buf_disc+$1e4
NM b) SP=4185ad48 RP=a.00b0b490 fclose_nm+$5e4
NM c) SP=4185ac88 RP=a.00b0ae78 ?fclose_nm+$8
export stub: a.00e97954 FCLOSE+$b8
NM d) SP=4185aa08 RP=a.00e97868 ?FCLOSE+$8
export stub: 7a9.01038ac0 NBCLOSE_passthru+$144
NM e) SP=4185a948 RP=7a9.0103b35c nbclosefile.localclose+$48c
NM f) SP=4185a888 RP=7a9.0103ba74 nbclosefile+$504
NM 10) SP=4185a7c8 RP=7a9.0103c938 FCLOSE+$44
NM 11) SP=41859588 RP=7a9.0103c8e0 ?FCLOSE+$8
export stub: d31.0012bb0c
NM 12) SP=41859508 RP=d31.0012b5d8
Can't unwind. Error reading a value from virtual memory.
nmdat > lev 4;dv psp-28,2
VIRT $339c.4185c2a8 $ 0000000b 84000700
nmdat > fv 84000700 'semaphore_rec'
RECORD
SEM_INFO_WORD :
SEM_STATE : 2
SEM_LOCK : 0
SEM_SPEC : 2
SEM_CLASS : 1c <-- semcl_pm_pcl
SEM_OWNER : 57a <-- PEUTIL
SEM_SPIN_STATE_REC :
SPIN_SEM_STATE : 0
SPIN_SEM_LOCK : 0
SPIN_SEM_SPEC : 0
SPIN_SEM_CLASS : 0
SPIN_SEM_OWNER : c0
SEM_SPIN_OWNER_COUNT : 418
END
So we have a deadlock between PEUTIL, which owns the PCL
semaphore and wants the
GUFD semaphore for file xxxx.xx.xxxxxx, and xxxx.xxx.xxxxxx,
which has the GUFD
semaphore for the PE file and wants the PCL semaphore.
There is little about this exact hang in KMINE, so I believe
it best if I submit
a new SR. It is my belief that running PEUTIL on a fully
loaded system and
doing a DISALLOW is probably not a recommended action, since
it disables PE
access for all users. It appears that PEUTIL should be
treated like FSCHECK,
and only run on a system that is quiet, thereby avoiding the
deadlock that
occurs from PEUTIL locking things in the wrong order. I am
submitting the SR so
that a header statement can be added to PEUTIL to warn users
that the utility is
best used on a quiet system.
The current PEUTIL header:
:peutil.pub.sys
peutil >
There is none...so something like this would be nice:
:peutil.pub.sys
WARNING: PEUTIL should be used only when a system is QUIET,
and currently
experiencing no activity. Use of this utility on a busy
system may result in a
hang condition. peutil >
|
