HP3000-L Archives

September 1995, Week 4

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Mike Hornsby <[log in to unmask]>
Reply To:
Mike Hornsby <[log in to unmask]>
Date:
Mon, 25 Sep 1995 12:10:36 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (75 lines)
On Sun, 24 Sep 1995, Paul H. Christidis wrote:
 
> I've been following this thread with great interest and have tried almost
> all of the presented suggestions, without any luck.  I have a session that
> has been hung for almost a week and although it does not interfere with the
> backups it is accessing the application's dictionary and thus would cause
> problems if updates to the dictionary become necessary.   Rebooting cannot
> be performed for at least another week.  I guess we'll cross our fingers
> and hope that we can last until then.
>
> I'm attaching a 'stack trace' of the hung process hoping that someone may
> see something that would identify the cause of the hang and provide some
> hints to a solution. (The process is native mode QUIZ.CURRENT.COGNOS).
>
> Thanks
>
> Paul H. Christidis
>
>
>
> Procedure Trace for Pin  118 is:
>
>        PC=a.0015270c enable_int+$2c
> NM* 0) SP=4184c030 RP=a.0027fa5c notify_dispatcher.block_current_process+$2f0
> NM  1) SP=4184c030 RP=a.00281ea8 notify_dispatcher+$264
> NM  2) SP=4184bfb0 RP=a.00182bd0 wait_for_active_port+$ec
> NM  3) SP=4184beb0 RP=a.00183850 receive_from_port+$534
> NM  4) SP=4184be30 RP=a.003191e8 extend_receive+$494
> NM  5) SP=4184bc30 RP=a.00307cc4 rendezvousio.get_specific+$158
> NM  6) SP=4184bab0 RP=a.00308028 rendezvousio+$1d8
> NM  7) SP=4184b9f0 RP=a.00e74ce4 attachio.perform_io+$1e0
> NM  8) SP=4184b670 RP=a.00e75c20 attachio.terminal_functions+$da0
> NM  9) SP=4184b5b0 RP=a.00e7a744 attachio+$2e8
> NM  a) SP=4184b470 RP=a.00302168 ?attachio+$8
>          export stub: a.00dfb9c4 arg_regs+$28
> NM  b) SP=4184b170 RP=a.00dbe4ec nm_switch_code+$94c
> NM  c) SP=4184b040 RP=a.00daabec SWT_RETURN
>        (switch marker frame)
>    CM       SYS  % 226.404    SWITCH'TO'NM'+%4       (Mitroc CCG)  SUSER1
>    CM *  0) SYS  % 226.404    SWITCH'TO'NM'+%4       (Mitroc CCG)  SUSER1
>    CM    1) SYS  % 162.10216  ATTACHIO+%201          (Mitroc CCG)  CMSWITCH
>    CM    2) SYS  % 154.2077   PRIMEDEVICE+%64        (Mitroc CCG)  ALLOCSEG
>    CM    3) SYS  % 167.17277  F'OPEN'+%11772         (Mitroc CCE)  FSSEG3
>    CM    4) switch marker                            (Mitroc CCG)
> NM  d) SP=4184ad00 RP=a.00dbd198 switch_to_cm+$828
> NM  e) SP=4184ab10 RP=a.00a9dcdc f_open_+$578
> NM  f) SP=4184a790 RP=a.00a9f32c call_old_open_p+$5f4
> NM 10) SP=4184a350 RP=a.00ba43e8 tm_open_device+$f8
> NM 11) SP=418495d0 RP=a.00a95d7c open_old.call_type_manager+$714
> NM 12) SP=41849390 RP=a.00a97240 open_old+$ae8
> NM 13) SP=41849290 RP=a.00a9bbb8 fopen_nm+$494
> NM 14) SP=41849090 RP=a.00a9b6f0 ?fopen_nm+$8
>          export stub: a.00df5c70 FOPEN+$98
> NM 15) SP=41848050 RP=a.00df5ba4 ?FOPEN+$8
>          export stub: 6b8.000837f4
> NM 16) SP=41847fd0 RP=6b8.00096af0
> NM 17) SP=41847ed0 RP=6b8.000982ec
> NM 18) SP=41847b50 RP=6b8.0008dedc
> NM 19) SP=41847990 RP=6b8.0008e2ac
> NM 1a) SP=418476d0 RP=6b8.00088e90
> NM 1b) SP=41847690 RP=6b8.000db0dc
> NM 1c) SP=41847650 RP=6b8.000db540
> NM 1d) SP=41847590 RP=6b8.000dbe5c
> NM 1e) SP=41847450 RP=6b8.000645c0
> NM 1f) SP=41847410 RP=6b8.00063318
> NM 20) SP=41847350 RP=6b8.00170720
> NM 21) SP=41847310 RP=6b8.00061f0c
> NM 22) SP=418461b0 RP=6b8.00000000
>      (end of NM stack)
>
 
i think the program is opening a device hot. do a showdev to see if any
are unavailable or in use by this process. then try abortio or termdsm
to reset the port.

ATOM RSS1 RSS2