dhesi@bsu-cs.UUCP (Rahul Dhesi) (01/27/88)
Is anybody aware of a bug (and possibly a fix) in 4.3BSD as distributed
by UCB for VAX machines that causes the system to undergo silent death
(no error messages of any kind, just hangs up until rebooted) if one or
more disk partitions get close to being full (but not actually full)?
Our configuration is a VAX-11/785 with one rp07 and two rm80 disks.
--
Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesichris@mimsy.UUCP (Chris Torek) (01/27/88)
In article <1960@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: >Is anybody aware of a bug (and possibly a fix) in 4.3BSD as distributed >by UCB for VAX machines that causes the system to undergo silent death >(no error messages of any kind, just hangs up until rebooted) if one or >more disk partitions get close to being full (but not actually full)? No, but if one *does* get full (to 100%---110% is not necessary) and someone types ^C or some other flush character while the system is printing `/usr: file system full', that can do it. `ps' on the crash dump will show various processes stuck in inode wait (`STAT' D). From: bostic@OKEEFFE.BERKELEY.EDU (Keith Bostic) Newsgroups: comp.bugs.4bsd.ucb-fixes Subject: V1.21 (ttycheckoutq) Message-ID: <8704302022.AA22430@okeeffe.Berkeley.EDU> Date: 30 Apr 87 20:22:06 GMT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 105 Approved: ucb-fixes@okeeffe.berkeley.edu Subject: ^C during 'file system full' messages can hang your system Index: sys/{tty.c,subr_prf.c} 4.3BSD Description: While printing "file system full" messages, ttycheckoutq() allows the system call to be interrupted, leaving inodes locked. Fix: echo x - subr_prf.c.diff sed 's/^X//' >subr_prf.c.diff << 'END-of-subr_prf.c.diff' X*** subr_prf.c Thu Apr 30 13:17:12 1987 X--- subr_prf.c.new Thu Apr 30 12:29:15 1987 X*************** X*** 67,72 **** X--- 67,74 ---- X /* X * Uprintf prints to the current user's terminal. X * It may block if the tty queue is overfull. X+ * No message is printed if the queue does not clear X+ * in a reasonable time. X * Should determine whether current terminal user is related X * to this process. X */ X*************** X*** 87,94 **** X if (p->p_uid != u.u_uid) /* doesn't account for setuid */ X return; X #endif X! (void)ttycheckoutq(tp, 1); X! prf(fmt, &x1, TOTTY, tp); X } X X /* X--- 89,96 ---- X if (p->p_uid != u.u_uid) /* doesn't account for setuid */ X return; X #endif X! if (ttycheckoutq(tp, 1)) X! prf(fmt, &x1, TOTTY, tp); X } X X /* END-of-subr_prf.c.diff echo x - tty.c.diff sed 's/^X//' >tty.c.diff << 'END-of-tty.c.diff' X*** tty.c Thu Apr 30 13:17:12 1987 X--- tty.c.new Thu Apr 30 12:25:12 1987 X*************** X*** 1256,1279 **** X * (from uprintf/tprintf). Allow some space over the normal X * hiwater mark so we don't lose messages due to normal flow X * control, but don't let the tty run amok. X */ X ttycheckoutq(tp, wait) X register struct tty *tp; X int wait; X { X! int hiwat, s; X X hiwat = TTHIWAT(tp); X s = spltty(); X if (tp->t_outq.c_cc > hiwat + 200) X while (tp->t_outq.c_cc > hiwat) { X ttstart(tp); X! if (wait == 0) { X splx(s); X return (0); X } X tp->t_state |= TS_ASLEEP; X! sleep((caddr_t)&tp->t_outq, TTOPRI); X } X splx(s); X return (1); X--- 1256,1283 ---- X * (from uprintf/tprintf). Allow some space over the normal X * hiwater mark so we don't lose messages due to normal flow X * control, but don't let the tty run amok. X+ * Sleeps here are not interruptible, but we return permaturely X+ * if new signals come in. X */ X ttycheckoutq(tp, wait) X register struct tty *tp; X int wait; X { X! int hiwat, s, oldsig; X X hiwat = TTHIWAT(tp); X s = spltty(); X+ oldsig = u.u_procp->p_sig; X if (tp->t_outq.c_cc > hiwat + 200) X while (tp->t_outq.c_cc > hiwat) { X ttstart(tp); X! if (wait == 0 || u.u_procp->p_sig != oldsig) { X splx(s); X return (0); X } X+ timeout(wakeup, (caddr_t)&tp->t_outq, hz); X tp->t_state |= TS_ASLEEP; X! sleep((caddr_t)&tp->t_outq, PZERO - 1); X } X splx(s); X return (1); END-of-tty.c.diff exit -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris