Subject: Re: Installing NetBSD on DEC 3000 M600S
To: None <firstname.lastname@example.org>
From: Miles Nordin <carton@Ivy.NET>
Date: 01/10/2006 19:35:39
Content-Type: text/plain; charset=US-ASCII
>>>>> "mtm" == Mark Ter Morshuizen <email@example.com> 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
(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
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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (NetBSD)
-----END PGP SIGNATURE-----