deb@gt-cmmsr.UUCP (Deborah Jackson) (02/05/86)
We have a very strange problem with our telnet program. Our Vax 11/780 is running 4.2BSD (BRL) UNIX(TM). The problem is that it seems to have its own version of flow control which follows no protocol. Whenever invoked, either through our ethernet to our Data General or through the software loop-back to itself, it stops after a seemingly arbitrary number of characters. Typing any character (except ^S) causes it to continue it's output. Those characters are stored up (i.e. type-ahead) and displayed after it's finished cat'ing a file, etc. Since any character will restart it, it's impossible to interupt a program's output -- ^Z doesn't work either. (It's a general nuisance.) Here are the things I know for sure: 1) It doesn't matter whether the built-in flow control switch is set or not 2) telnet from the Data General to the Vax works just fine, so I don't think it's a psuedo-port problem or a telnetd problem. 3) Decreasing BUFSIZ (to force more flushes) helps a little, but doesn't solve the problem. 4) rlogin works just fine (but the DG can't handle it--otherwise I wouldn't care if telnet worked or not!) 5) ftp also runs without a hitch. I've worked on several Vaxen running 4.2BSD and never seen this problem. I've also never worked on a Vax with dmf32's before now, which leads me to believe they are the culprit. Has anyone ever seen this problem? Has anyone run telnet with dmf32's??? Any suggestions are greatly appreciated. Thanks in advance, Deb -- Deborah Jackson School of Electrical Engineering, Georgia Tech, Atlanta, GA 30332 uucp: ...!{akgua,allegra,hplabs,ihnp4,seismo,ulysses}!gatech!gt-eedsp!deb ^^^^^
chris@umcp-cs.UUCP (Chris Torek) (02/06/86)
This is a bug in the dmf32 driver. I have seen several versions of the driver with the same bug (including one I was running for some time; I fixed it about an hour after posting it to net.sources, as I recall . . .). Look at /sys/vaxuba/dmf.c. Find the routine `dmfstart'. It will have a few lines commented something like this: /* * If there are sleepers, and output has drained below low * water mark, wake 'em up. */ The code under this comment *should* look like this: 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; } } but the `if (tp->t_wsel)' clause is missing. Add it, compile and boot the new kernel, and all should be well again. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1415) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu
abe@pucc-j (Vic Abell) (02/06/86)
In article <134@gt-cmmsr.UUCP> deb@gt-eedsp.UUCP (Deborah Jackson) writes: > >We have a very strange problem with our telnet program. Our Vax 11/780 >is running 4.2BSD (BRL) UNIX(TM). >. . . Whenever invoked, >either through our ethernet to our Data General or through the software >loop-back to itself, it stops after a seemingly arbitrary number of >characters. . . >I've also never worked on a Vax with dmf32's before now, which leads me >to believe they are the culprit. Yes, the problem is a missing selwakeup() call in dmfstart() of dmf.c. One should be inserted after line 533 (approximately): dmfstart(tp) . . . if (tp->t_wsel) { =====> selwakeup(tp->t_wsel, tp->t_state & TS_WCOLL); tp->t_wsel = 0; tp->t_state &= ~TS_WCOLL; }