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>