Subject: Re: Installing NetBSD on DEC 3000 M600S
To: None <>
From: Miles Nordin <carton@Ivy.NET>
List: port-alpha
Date: 01/10/2006 19:35:39
Content-Type: text/plain; charset=US-ASCII

>>>>> "mtm" == Mark Ter Morshuizen <> writes:

   mtm> I reckon there's a bug, either in minicom or in whatever piece
   mtm> of code talks to the serial console on my 3000.

I don't remember minicom's flow control setting features, but you can
escape to a shell and use stty to check or turn on/off flow control on
the minicom machine

$ stty -a < /dev/tty00
$ stty crtscts < /dev/tty00
$ stty -crtscts < /dev/tty00
$ fg

(though there is not much you can do about the other end, so just
turning on/off flow control on the minicom end can't solve every
imagineable problem.)

You might use a voltmeter to measure the state of the pins since a few
combinaions of mismatch are possible (not generating outbound RTS,
flow control miswired but not ignoring incoming CTS, miswiring, DTR
not looped back so hung waiting for CD/DSR,...).

When using NetBSD's 'cu' I find that if I start 'cu' with a particular
cable setup (ex. one with/out flow control pins working) then 'cu'
will work, but if I change between working and nonworking flow
control, I'll have to restart 'cu' before it works again.  never
really bothered tracking down a mechanism because the fix is quick and
brainless and I am so impatient with sysadmining these days, but I
suspect programs other than 'cu' might be stricter.

Also please consider it's only a _chance_ your problem is hardware
flow control.  The problem could still be something else, driver bug,
obscure srm variable setting, who knows what.

Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

Version: GnuPG v1.4.2 (NetBSD)