Path: utzoo!utgpu!watmath!clyde!att!rutgers!mit-eddie!uw-beaver!rice!sun-spots-request From: newroot@physicsa.mcgill.ca (Operator) Newsgroups: comp.sys.sun Subject: More about system hang-ups Message-ID: <8811210525.AA11545@frodo.physicsa.mcgill.ca> Date: 2 Dec 88 19:48:53 GMT Sender: usenet@rice.edu Organization: Rice University, Houston, Texas Lines: 40 Approved: Sun-Spots@rice.edu Original-Date: Mon, 21 Nov 88 00:25:20 EST X-Sun-Spots-Digest: Volume 7, Issue 33, message 3 of 12 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@physicsa.mcgill.ca Physics, McGill University Montreal Quebec CANADA