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
booting.

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
often non-intuitive.

> 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
> beforehand.

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?"
> modes).  

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
particular terminal.

> 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.

-- 
shannon@widomaker.com  _________________________________________________
______________________/ armchairrocketscientistgraffitiexenstentialist
 "And in billows of might swell the Saxons before her,-- Unite, oh
 unite!  Or the billows burst o'er her!" -- Downfall of the Gael