Serial console problems with stable/8
freebsd at jdc.parodius.com
Mon Sep 13 18:19:44 UTC 2010
On Mon, Sep 13, 2010 at 06:59:58PM +0200, Oliver Fromme wrote:
> John Baldwin wrote:
> > On Monday, September 13, 2010 11:55:27 am Oliver Fromme wrote:
> > > I think the boot.config stuff might be a red herring.
> > > The console breaks (i.e. freezes) as soon as I try to run
> > > a getty process on it -- That seems to indicate that getty
> > > does *something* to the console device which causes the
> > > problem. The wchan "ttydcd" seems to indicate is has
> > > something to do with carrier detection or flow control.
> > > This points to the uart driver as the culprit which
> > > replaced sio.
> > Well, /dev/ttyXX have always waited for carrier detect, whereas
> > /dev/cuaXX (the call-out devices) have not.
> Well, before the update I had ttyd0 in /etc/ttys (this is
> the default in FreeBSD 7.x), so it should have waited for
> carrier detect, too.
Re-adding ed@ to the CC list. I hope he can shed some light on this.
I believe FreeBSD expects DCD to be raised on both sio(4) and uart(4)
when /dev/ttyuX devices are used -- however, see item 3 below. We've
upgraded numerous servers of ours from RELENG_6 and RELENG_7, to
RELENG_8, with no serial console issues (we still have some RELENG_6 and
RELENG_7 boxes in use as well, using sio(4), so we can provide details
from those too if need be). Our cabling/hardware differs from yours
> > That was so that you could hook a modem up to a serial port and getty
> > would not return from open(2) and print a login banner until someone
> > dialed the modem and connected. I think Jeremy has already given you
> > some good things to try (such as 3wire.9600) to debug this instead.
> Yes, I will try that ... But with the 3wire entry I won't
> have any flow control at all, so output can be lost, right?
> Doesn't sound like a good solution.
1) gettytab(5) mentions the "mb" capability, which tells it to do flow
control based on DCD, I believe. This defaults to off, and isn't
defined for the std.XXX nor 3wire.XXX entries.
2) However, I imagine some null modem adapters or cables might wire RTS
and CTS to DCD. Check out Table 26-2 for DB9 to DB9 null modem cable
wiring, and be sure to check out the paragraph *after* "Note:" in Table
3) But here's the fun part! The adapters I use in our co-location (DB9
serial ports on PCs wired to a MRV unit), pin 1 (DCD) on the DB9 serial
port *is not* wired -- it literally hangs loose. The adapters use
hardware flow control (CTS/RTS), and all equipment is configured to use
it as well. We use the following line in /etc/ttys reliably (without
any character loss):
ttyu0 "/usr/libexec/getty std.115200" xterm on secure
The exact pinout is below:
(CTS) 1 <----> 7 (RTS)
(DTR) 2 <----> 6 (DSR)
(TxD) 3 <----> 2 (RxD)
(TxD GND) 4 <----> 5 (GND)
(RxD GND) 5 <----> 5 (GND)
(RxD) 6 <----> 3 (TxD)
(DSR/DCD) 7 <----> 4 (DTR)
(RTS) 8 <----> 8 (CTS)
I can provide stty -a -f /dev/ttyuX output on one of these machines if
folks would find it useful as a comparison model to what Oliver's
Is it possible the null modem adapter, cables, or jacks been slightly
jostled or anything like that? Hrm, actually I guess that's pointless
to ask since you can restore proper behaviour rolling back to RELENG_7.
: Prior to logging in, there is no flow control -- this happens on
sio(4) as well as uart(4). This problem dates back to at least the
FreeBSD 4.x days and is easily detectable by hitting enter repetitively
at the "login:" prompt on a serial console; occasionally the output will
get messed up. Once you log in, however, flow control works fine. When
I chatted with Marcel Moolenaar about this, he assured me this is
expected. This isn't the problem you're seeing, but I thought I'd
mention it in passing anyway.
| Jeremy Chadwick jdc at parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |
More information about the freebsd-stable