More about system hang-ups

Operator newroot at physicsa.mcgill.ca
Sat Dec 3 05:48:53 AEST 1988


As an addendum to my previous plea for help concerning our recurrent
system hang-ups, I am posting an example of a typical traceback provided
by adb on the system core dump to see if it strikes any familiar chords.
To recap, the machine afflicted is a 3/180 acting as fileserver to 5
client 3/50's running SUN OS3.5.  It has an ALM-2 for terminal access.

The machine tends to start slowing (as if a single process is robbing all
the cpu time) until there is no response from any console, terminal or
rlogin.  It continues to faithfully act as fileserver and ping shows it to
be alive.  It must be crashed from the monitor.  There are no obvious
concurrent operating conditions although this never happens at night.

_panic(0xf06fb8e) + 3e		\
_v_handler() + 52		|
_v_handler() + 52		|
_v_handler() + 52		|
_v_handler() + 52		|
_v_handler() + 52		|------ common to all core trace backs
_v_handler(0x4d,0xf079c1c) + 52	|
_zsa_process(0xf0809f0)	+ 1f0	|
_zspoll(0x0,0x0) + 24		|
_softclock(0x2004) + 86		|
_hardclock() + 292		|
level5(?)			/
_dirlook(0xf090fd2,0xf187330,0xffff861e) + 8a
_ufs_lookup(0xf090fda,0xf187330,0xffff867e,0xf2aff58) +	16
_rfs_lookup(0xf2afef0,0xf2aff84,0xffff86ea) + 40
_rfs_dispatch(0xffff86ea,0xf2ae99c) + 2a0
_svc_getreq(0xf2ae99c) + ee
_svc_run(0xf2ae99c) + 40
_nfs_svc(0xffff886a) + 10a
_syscall(0x9b) + dc
syscont() + 6
address	out of segment

If you see anything meaningful, send a note.

Loki Jorgenson              loki at physicsa.mcgill.ca
Physics, McGill University
Montreal Quebec CANADA



More information about the Comp.sys.sun mailing list