Serial console problems with stable/8

[Oliver Fromme]

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