Serial console problems with stable/8

[Jeremy Chadwick]

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.

>  > If so, I'm not too surprised it doesn't work (re: -P flag).
> 
> If -P is not supposed to activate the serial console, then
> 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).

-P does not activate serial console.  -P probes for a PS/2 keyboard.  If
one is attached, the system behaves like it would with a VGA console
attached.  Otherwise, if there is no PS/2 keyboard attached, it behaves
identically to the -D -h flags being set.

I do not know how -P internally works.  I imagine it speaks to the PIC
internal to the keyboard, or through a BIOS interrupt (0x10).  This is
why I asked what I did about the KVM switch above.

The -D and -h flags are somewhat confusing, so see the "table" in the
handbook for what does what (note the handbook which still references
sio(4) flags/bits, but those also apply to uart(4)):

http://www.freebsd.org/doc/handbook/serialconsole-setup.html

You'll find that FreeBSD does not offer a "true" dual console setup.
DragonflyBSD does offer this.

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

>  > Can you try the following?
>  > 
>  > 1) Removing kernel_options and console from loader.conf
>  > 2) Place "-P" in /boot.config instead
>  > 
>  > If this doesn't change the behaviour, please replace -P and with -D -h
>  > and see if there's any improvement.

> I already have tried all kinds of different combinations when I sat in
> front of the box yesterday.  I'm not sure if I have tried the exact
> combination that you suggest, though.  I also don't understand why
> those changes should improve anything.

Hopefully the reason why I'm asking you to try this makes more sense
with my above explanation of what -P actually does.

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

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.)?

Thanks!

-- 
| 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 |