Date: Mon, 13 Sep 2010 14:49:48 +0200 (CEST) From: Oliver Fromme <olli@lurza.secnetix.de> To: freebsd-stable@FreeBSD.ORG, freebsd@jdc.parodius.com, Stefan Bethke <stb@lassitu.de> Subject: Re: Serial console problems with stable/8 Message-ID: <201009131249.o8DCnmd4033849@lurza.secnetix.de> In-Reply-To: <20100913074050.GA45070@icarus.home.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
Jeremy Chadwick wrote: > On Mon, Sep 13, 2010 at 09:21:21AM +0200, Oliver Fromme wrote: > > Jeremy Chadwick wrote: > > > Is there a PS/2 keyboard hooked up to this machine when you're > > > attempting to get serial console output? > > > > Kind of. It's connected to a local KVM switch. > > Does the KVM switch provide power to a PS/2 port which isn't currently > selected? (E.g. on an A/B/C/D KVM switch, if the FreeBSD box is wired > to port A, and the KVM switch has port C selected, does port A still get > power?) Some KVMs do this, others do not. Yes, it does. Now I get your point ... Yes, -P does probe the keyboard first. That's probably why I see the boot0/boot2 on the VGA console, not on the serial port. As far as I know, /boot.config is read by the boot0/boot2 stage, not by loader(8). Anyway, I don't care too much for boot0/boot2; I've never had to interact with them on that machine. The important thing for me is that loader(8) and the kernel use the serial port for the console, and that I can login on it (i.e. there must be a getty running). All of that seemed to be accomplished with the console="comconsole" entry in /boot/loader.conf ... At least it worked when I first installed that machine in September 2000 (yeah, exactly 10 years ago) with FreeBSD 4.1, then updated it roughly every two years ... And it stopped working in 8.x. I will try your suggestion of replacing -P with -Dh, next time I'm at the site (probably Friday). It's too risky to try that remotely, given that I had to press the hard reset button several times yesterday during my attempts of getting the serial console to work as it should. Fortunately the machine has a small disk, so fsck finishes in only two or three minutes ... However, I fear that it won't improve things. I don't see how it could change the symptoms I'm seeing. The serial console _is_ activated (through the loader.conf entry), but it just doesn't work correctly. > > the boot.config(5) manpage is in urgent need of a fix. > > Quote: > > > > > The command: > > > > > > # echo "-P" > /boot.config > > > > > > will activate the serial console of FreeBSD. > > That's a highly misleading description, and should probably be removed. > It's better to read boot(8). Agreed. > http://www.freebsd.org/doc/handbook/serialconsole-setup.html I did have exactly the settings listed in section 26.6.2: console="comconsole" in loader.conf and the getty turned on in /etc/ttys. And specifically, section 26.6.6.1 states: | You can easily specify the boot loader and the kernel | to use the serial console by writing just one line in | /boot/loader.conf: | | set console="comconsole" | This will take effect regardless of the settings in the | boot block discussed in the previous section. So, it's pretty much irrelevant whether I have -P or -Dh or anything else (or nothing at all) in /boot.config. > You'll find that FreeBSD does not offer a "true" dual console setup. > DragonflyBSD does offer this. True. I'm aware of that. I don't need dual console. > > Also, with that flag it has worked fine for ages, until > > I updated to 8.1-stable. There must be a regression > > somewhere. > > I don't know if the regression is with PS/2 keyboard probing or with the > introduction of uart(4) as the default serial port driver. I'm CC'ing > ed@ since he's worked heavily on uart(4) and can assist here. I'm guessing it is uart's fault, but I haven't dug deeply enough to be certain. > > BTW, the interesting thing is that all processes that try to access > > the console hang in "ttydcd". I'm not familiar with the tty code ... > > Does anyone have an idea what this means? > > I imagine it means the tty driver (thus uart(4)) is waiting for the DCD > line on the serial port to either go low or high (not sure which), but I > could be completely wrong. > > One more thing to try: can you replace "std.9600" in your /etc/ttys > with "3wire.9600" and then do "init q" and see if things improve? This > should remove carrier detection (DCD) from the mix. That sounds like a very good suggestion! Will try that. > If using 3wire.9600 works, can you provide a description of the wiring > of your serial console setup? Specifically what DB9 pin is connected to > what on the remote end, and what the remote end actually is (Xyplex > unit, another PC, etc.)? The remote end is another PC running FreeBSD (still 7.x). I use tip(1) running inside a screen(1) session on that remote PC to connect to my serial console. The cable is a standard nullmodem cable, not selfmade. It's a DB9-to-DB9 cable labelled "nullmodem", so I guess it's correctly wired including carrier / handshake, i.e. not just a 3-wire cable. (And it did work fine from FreeBSD 4.x to 7.x ... sorry for repeating myself.) Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "In My Egoistical Opinion, most people's C programs should be indented six feet downward and covered with dirt." -- Blair P. Houghton
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201009131249.o8DCnmd4033849>