Date: Mon, 08 May 1995 01:23:15 -0700 From: Steven Wallace <swallace@balboa.eng.uci.edu> To: davidg@Root.COM Cc: freebsd-bugs@FreeBSD.org Subject: Re: freeze up Message-ID: <9505080823.AA06479@newport.ece.uci.edu> In-Reply-To: Your message of "Mon, 08 May 1995 00:06:22 PDT." <199505080706.AAA00158@corbin.Root.COM>
next in thread | previous in thread | raw e-mail | index | archive | help
>>So I found this experience very odd because existing processes continued >>to run fine until they ran into something that blocked them from continuing >>anymore while new commands (ls, kill, ps I tried) would freeze right >>away - until I terminated this cc process. Any ideas on what this could >>be? What should I do if I experience this freeze with a partial lock-up? > > Sounds like a vnode locking problem that eventually leads to locking the > root directory (at which point your dead). I don't know what could be causing > it, though. wcarchive is running -current from about 3 days ago and has been > up running fine since (and this is with 250-300 users and mild paging) and I > haven't seen the problem on my own machines. We did have problems like this > a month or so ago, but the causes of those have been fixed. As far as what to > do next time it happens...hmmm, if you can get to the console vty, you could > escape to the debugger and do a 'ps' to find out what the processes are all > sleeping on. Since your windows appear to still be mostly alive, you might try > typing "ctrl-T" and noting the wmesg (the part in brackets that comes after > the PID). This would provide more clues, perhaps. > Okay, I am writing you live with a vnode lockup (again) :) One other factor I didn't mention is the last two weeks I have been working on my application that used shared memory mapping frequently. This time the lockup seems to hinting toward a memory mapped prob. Take a look at what I did: pal-r32-a07b-gs >> fg textscr ebank ^C pal-r32-a07b-gs >> fg shr ebank 12000 ^C pal-r32-a07b-gs >> rmf ebank ^C^C^C The two programs textscr and shr share the file named ebank. I quit those two programs leaving nothing using the resource any longer. Then the filesystem hung when attempting to remove the file. Perhaps there were some dirty pages in there and it had a problem writing it back or something along those lines. Here is my ps listing. I think I will go to sleep now. I will check my email in the morning if you have any other commands you wish me to type before I reboot. I have one shell in which to put commands in the background. Steven pal-r32-a07b-gs >> ps -a & [5] 539 pal-r32-a07b-gs >> PID TT STAT TIME COMMAND 200 p0 IWs+ 0:00.23 -csh (tcsh) 199 p1 IWs+ 0:00.42 -csh (tcsh) 198 p2 IWs+ 0:00.27 -csh (tcsh) 238 p3 Is 0:00.63 -csh (tcsh) 512 p3 D+ 0:00.01 /bin/rm -f ebank 241 p4 Ss+ 0:00.92 -csh (tcsh) 513 p4 D 0:00.01 ls -CF 517 p4 D 0:00.01 ls -CF / 518 p4 D 0:00.01 ls -CF /tmp 523 p4 S 0:00.37 xterm -T free -n free -e rlogin free 527 p4 S 0:00.29 xterm -T newport -n newport -e rlogin newport 533 p4 I 0:00.24 xterm 539 p4 R 0:00.00 ps -a 245 p5 IWs+ 0:00.79 rlogin newport 248 p5 IW+ 0:00.53 rlogin newport 524 p6 Is+ 0:00.11 rlogin free 525 p6 I+ 0:00.03 rlogin free 528 p7 Is+ 0:00.09 rlogin newport 529 p7 I+ 0:00.01 rlogin newport 534 p8 Ds+ 0:00.04 tcsh 168 v0 IWs 0:00.31 -tcsh (tcsh) 178 v0 IW+ 0:00.09 xinit 180 v0 S 0:09.35 fvwm -display :0 186 v0 IW 0:00.67 xterm -fn 9x15 -geometry 80x24+0+34 #+0+0 -s -sb -n << 188 v0 S 0:04.39 xclock -digital -geometry 185x24+0+0 -bw 1 -update 1 190 v0 IW 0:00.96 xterm -sb -fn 9x15 -geometry 80x30+0-0 -title Shell -n 192 v0 IW 0:00.30 xterm -sb -fn fixed -geometry 80x65-0+0 -title Shell - 196 v0 IN 2:02.33 xearth -nice 10 197 v0 I 0:00.22 /usr/X11R6/lib/X11/fvwm/GoodStuff 8 5 /users/swallace/ 237 v0 I 0:01.18 xterm -n Shell 240 v0 R 0:28.32 xterm -n Shell 244 v0 IW 0:02.74 xterm -T newport -n newport -e rlogin newport 247 v0 I 0:24.09 emacs 374 v0 IW 0:00.38 hexcalc 169 v1 IWs+ 0:00.02 /usr/libexec/getty Pc ttyv1 170 v2 IWs+ 0:00.02 /usr/libexec/getty Pc ttyv2 171 v3 IWs+ 0:00.02 /usr/libexec/getty Pc ttyv3 172 v4 IWs+ 0:00.02 /usr/libexec/getty Pc ttyv4 173 v5 IWs+ 0:00.02 /usr/libexec/getty Pc ttyv5 208 a0 IWs+ 0:00.01 slattach -l -s 38400 /dev/cuaa0
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9505080823.AA06479>