Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 13 Sep 2010 11:19:42 -0700
From:      Jeremy Chadwick <freebsd@jdc.parodius.com>
To:        Oliver Fromme <olli@lurza.secnetix.de>
Cc:        ed@freebsd.org, freebsd-stable@freebsd.org, Stefan Bethke <stb@lassitu.de>, John Baldwin <jhb@freebsd.org>
Subject:   Re: Serial console problems with stable/8
Message-ID:  <20100913181942.GA60085@icarus.home.lan>
In-Reply-To: <201009131659.o8DGxwvF044463@lurza.secnetix.de>
References:  <201009131223.25011.jhb@freebsd.org> <201009131659.o8DGxwvF044463@lurza.secnetix.de>

next in thread | previous in thread | raw e-mail | index | archive | help
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
though.

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

http://www.freebsd.org/doc/handbook/serial.html#SERIAL-CABLES-PORTS

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[1]):

ttyu0   "/usr/libexec/getty std.115200" xterm   on  secure

The exact pinout is below:

         RJ45          DB9
       Female          Female
  ===========          =======
      (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
seeing.

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.


[1]: 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@parodius.com |
| Parodius Networking                       http://www.parodius.com/ |
| UNIX Systems Administrator                  Mountain View, CA, USA |
| Making life hard for others since 1977.              PGP: 4BD6C0CB |




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100913181942.GA60085>