newroot@physicsa.mcgill.ca (Operator) (12/03/88)
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