Subject: Re: DEC vt320 terminal problem
To: NetBSD User's Discussion List <netbsd-users@NetBSD.ORG>
From: Shannon <firstname.lastname@example.org>
Date: 06/23/2001 19:04:16
On Sat, Jun 23, 2001 at 03:23:40PM -0400, Greg A. Woods wrote:
> The other day I had the opportunity to sit down at a real VT340
> connected to the console port of an i386 NetBSD box (over at my
> colleague Andreas').
Meanwhile I've been trying bids on Wyse 160E's and DEC vt510's... :)
> This machine would apparently freeze while booting, never getting past
> the point where 'init' tries to open /dev/console.
I have noticed that too, and it doesn't happen if I keep the terminal
in 7-bit mode at 9600bps. Wierd.
With DEC UNIX, SunOS, and OpenBSD I never lost the terminal when
For NetBSD-sparc, I have to go into firmware (terminal) and reset the
terminal and then everything is OK... or rather, the normal problems
then start... :)
> I've occasionally seen something very similar with machines I've had
> connected to terminal servers, and that's even after I hacked the com
> driver, and the serial boot code, and anywhere else in the kernel I
> could think of to make sure that the UART would not get stuck if the
> terminal had flow-controlled it during boot (that was with 1.3.3). On
With terminal servers, I found the fixes to things like this were
> those machines though the hang was usually sometime during the output
> from /etc/rc, not immediately as init started), and simply pressing any
> key would restore output. Nothing but a BREAK would wake up the i386
> (and that of course dumps you into DDB where a reboot is the only thing
> that gets you anywhere).
...which is immensely annoying. Good thing the sparc is happy to keep
going when you do things like that.
> I suspect that's because I normally have "ixon ixoff ixany" modes
> set once /etc/rc gets going, but I'll bet "-ixany" is the default
Is there a way to set serial port options at kernel boot? I mean,
besides actually changing the code.
> Once we got the machine booted up fine and working I tried reproducing
> the problem you described with shell prompt output (but in the way I'd
> reproduced it on the sparc serial console). Oddly, no go! At least not
> always like on the sparc.
I found much the same thing with Intel *BSD systems. I still haven't
tried this terminal on NetBSD, but I'm going to _try_ get around to
it this weekend.
> However with a certain amount of prompt output there are sometimes big
> fat backwards question-marks splattered in the output from when the
> terminal is flow controlled....
The fat ? usually means something like parity or character size (i.e.
7 vs 8 bits) is messed up. So if you see it now and then, you are
likely losing bits somewhere.
> Oh, and BTW, you really really do need and want "autowrap" enabled! ;-)
It's not helping me much... :(
> I'm going to take another look at the hacks I did to the com driver and
> the serial boot code and see if I can't fix the flow-control during boot
> problem once and for all....
I've looked around at the code in NetBSD, and the tcsh source code.
The shell won't necessarily be easy to fix. I have even wondered if
part of the problem is the termio/termcap libraries. Nothing
conclusive to report there, as I got tired of messing with this for
a couple of days.
> Though I think the ultimate solution is to
> re-introduce delay characters (i.e. stty's "cr? nl? tab? bs? ff? vt?"
I tried editing the termcap entry to enable that, but it seems to have
no effect unless I just did something wrong.
Another solution is to make the shells go to the next line by issuing
an actual linefeed instead of forcing a wrap and linefeed at the
last column. As I said in another message, it is that action that
differentiates shells which work from those which don't, on my
> They should never have been removed from termio[s] in *BSD (or
> rather they should have been implemented!).
Doh! If they aren't implemented, that would explain why my changes
seemed to have no effect.
> could be set more properly by default for serial terminals and flow
> control problems for kernel output could be avoided in the "proper" (er,
> proven) way. If I ever get that far I'll send-pr whatever I come up
> with! ;-)
Let me know. If I manage to make any headway with tcsh, I'll post
here. Other projects are starting to beg for attention, but I
plan to revist this at least one day a week until it gets fixed.
Even if I get a faster terminal, it may still be a problem.
"And in billows of might swell the Saxons before her,-- Unite, oh
unite! Or the billows burst o'er her!" -- Downfall of the Gael