4.2bsd/vax dmf driver bug fix (short diff listing)
der Mouse
mouse at mcgill-vision.UUCP
Sat Aug 10 09:54:15 AEST 1985
We just started getting netnews, so please forgive if this has been
mentioned.... There was a bug in our distribution's `dmf' device
driver. (How many of you have dmf cards on your vaxen :-)? Symptom
is that some programs (those which use select() to select a tty line
for write) will block every 200 or so characters of output and wait
until you type something before continuing. More precisely, this bug
caused a select() on a dmf terminal line to fail to notice when a
write, which was not initially possible, became possible. The change
is in /sys/vaxuba/dmf.c (of course), in dmfstart, where a test is
made to wake up sleepers when the outq drains below the low water
mark. The code wakes up processes blocked in write()s and should,
but doesn't, also wake up anyone blocked in a select(). The code we
are running appears to work correctly. Here is a diff listing (and
after it, a diff -e listing):
516c516,517
< * If output has drained below low water mark, wake up any sleepers.
---
> * If there are sleepers, and output has drained below low
> * water mark, wake up the sleepers.
518,528c519,522
< if (tp->t_outq.c_cc <= TTLOWAT(tp))
< { if (tp->t_state & TS_ASLEEP)
< { tp->t_state &= ~TS_ASLEEP;
< wakeup((caddr_t)&tp->t_outq);
< }
< if (tp->t_wsel)
< { selwakeup(tp->t_wsel,tp->t_state&TS_WCOLL);
< tp->t_wsel = 0;
< tp->t_state &= ~TS_WCOLL;
< }
< }
---
> if ((tp->t_state&TS_ASLEEP) && tp->t_outq.c_cc<=TTLOWAT(tp)) {
> tp->t_state &= ~TS_ASLEEP;
> wakeup((caddr_t)&tp->t_outq);
> }
Here's the diff -e listing:
519,522c
if (tp->t_outq.c_cc <= TTLOWAT(tp))
{ if (tp->t_state & TS_ASLEEP)
{ tp->t_state &= ~TS_ASLEEP;
wakeup((caddr_t)&tp->t_outq);
}
if (tp->t_wsel)
{ selwakeup(tp->t_wsel,tp->t_state&TS_WCOLL);
tp->t_wsel = 0;
tp->t_state &= ~TS_WCOLL;
}
}
.
516,517c
* If output has drained below low water mark, wake up any sleepers.
.
der Mouse
Hacker and general troublemaker
CVaRL, McGill University
Hacker: One responsible for destroying /
Wizard: One responsible for recovering it afterward
--
der Mouse
Hacker and general troublemaker
CVaRL, McGill University
Hacker: One responsible for destroying /
Wizard: One responsible for recovering it afterward
More information about the Comp.unix.wizards
mailing list