Mailing List Archive

[. On Tuesday, January 14, 2003 at 14:18:17 (-0500), Ernie Oporto wrote: ]
> Subject: How to tell Sun keyboard console from serial console?
>
> I there a way to tell whether a console is at the keyboard or at the
> serial port on a Sun machine? The "tty" command gives /dev/console for
> both.

It depends somewhat on the particular type of machine and on the OS that
you're running on it.

Normally I believe on all modern versions of Solaris (SunOS-5) the
/dev/console file is a symbolic link to the actual device file in the
/devices directory.

On most/many/all versions and variants of Unix since the very beginning
the console device is a pseudo device that's mapped inside the kernel to
whatever real device(s) are configured or probed to be the physical
console.

As you'll read in the console(7D) manual page:

DESCRIPTION
The file /dev/console refers to the system console device.

SPARC
The identity of this device depends on the EEPROM or NVRAM
settings in effect at the most recent system reboot; by
default, it is the ``workstation console'' device consisting
of the workstation keyboard and frame buffer acting in con-
cert to emulate an ASCII terminal (see wscons(7D)).

With Solaris 9 on a SunFire V100 I could find no particular hint in the
'dmesg' output suggesting how the console is attached.

On NetBSD it's pretty easy to see (especially if you also know what the
zs1 and zs0 devices are):

$ /sbin/dmesg | fgrep console
kbd0 at zs1 channel 0 (console input)
bwtwo0 at sbus0 slot 2 offset 0x0 level 9: SUNW,501-1419, 1600 x 1280 (console)

$ /sbin/dmesg | fgrep console
zstty0 at zs0 channel 0 (console i/o)

You can also query the EEPROM/NVRAM settings on NetBSD and on Solaris:

On NetBSD:

# eeprom 2>/dev/null | fgrep put-device=
output-device=ttya
input-device=ttya

# eeprom 2>/dev/null | fgrep put-device=
output-device=screen
input-device=keyboard

On SunOS:

$ /usr/platform/`uname -i`/sbin/eeprom | fgrep put-device=
output-device=screen
input-device=keyboard

I'm not sure which information source you should trust more on Solaris,
but on NetBSD it's definitely the 'dmesg' output that's authoritative.

--
Greg A. Woods

+1 416 218-0098; <g.a.woods@ieee.org>; <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>

As long as the kbd was not attached at time of power-on, then console is
not the framebuffer. If a kbd was attached at power and a /dev/fb exists,
console will be framebuffer unless eeprom is set specifically to ttya (or rsc).

Although its probably logged somewhere, the info in that logfile might be
stale or overwritten. You can determine if the console is the framebuffer
or not with: "prtconf -F".

Excerpt from manpage:

-F (SPARC only). Returns the device path name of the con-
sole frame buffer, if one exists. If there is no frame
buffer, prtconf returns a non-zero exit code. This
flag must be used by itself. It returns only the name
of the console, frame buffer device or a non-zero exit
code. For example, if the console frame buffer on a
SPARCstation 1 is cgthree in SBus slot #3, the command
returns: /sbus@1,f80000000/cgthree@3,0. This option
could be used to create a symlink for /dev/fb to the
actual console device.

examples:

:Ultra80 workstation (kbd/fb attached)

ultra80(2)% prtconf -F
/SUNW,afb@1e,0:afb0

:Ultra5 "server". No kbd but has onboard PGX.

ultra5(1)% prtconf -F
Console output device is not a frame buffer

:NetraT1

netra-t1-105(1)% prtconf -F
Console output device is not a frame buffer

[. On Sunday, January 19, 2003 at 19:18:06 (-0500), Michael Dolan wrote: ]
> Subject: Re: How to tell Sun keyboard console from serial console?
>
> As long as the kbd was not attached at time of power-on, then console is
> not the framebuffer.

Substitute /power-on/ for /boot/ and you're probably right.

> If a kbd was attached at power and a /dev/fb exists,
> console will be framebuffer unless eeprom is set specifically to ttya (or rsc).

I'm pretty sure it does not matter whether the file or linkg "/dev/fb"
exists or not, but otherwise I think that's essentially true.

> Although its probably logged somewhere, the info in that logfile might be
> stale or overwritten. You can determine if the console is the framebuffer
> or not with: "prtconf -F".

I'm not sure that's the same as knowing whether the kernel thinks it's
"console" pseudo-device is attached to the KBD & FB or not, and I
wouldn't want to bet on it without seeing the source.... :-)

--
Greg A. Woods

+1 416 218-0098; <g.a.woods@ieee.org>; <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>

On Sun, 19 Jan 2003, Greg A. Woods wrote:

> Date: Sun, 19 Jan 2003 19:32:57 -0500 (EST)
> Substitute /power-on/ for /boot/ and you're probably right.

True. If you reboot/reset from a workstation console and pull the kbd in
time... :)

> I'm not sure that's the same as knowing whether the kernel thinks it's
> "console" pseudo-device is attached to the KBD & FB or not, and I
> wouldn't want to bet on it without seeing the source.... :-)

I think "prtconf -F" will suffice for most queries, but if you want to be
sure, try this... clumbsy but functional, and you might not want to do it
in absolute mission critical environments during production hours:

# adb -k /dev/ksyms /dev/mem
wscons/D

wscons: 1 (workstation console, ie kbd/fb)

or

wscons: 0 (ttya, ttyb, rsc, other?)

I tested this under solaris7 - 9 on various workstations with kbd/fb and
servers w/o, including E10K and SFx800, results were consistent. See
wscons(7d) for more info.

It might be useful (or not) to point out that you can ensure console
output is always ttya by setting eeprom variables to such. (Caveat being
E10K, SFx800, and RSC consoles). You can serial consoles on graphical
workstations by setting the eeprom variables to ttya, ttyb or rsc and
modify your Xservers file (replace 'console' with 'none' for :0).

In addition, the consadm (1m) facility (s7 and higher?) adds support for
auxilary consoles. Besides the default console, you can add additional
consoles for output (and input up through single-user mode). You can add a
second console to a running system and attach to it read-only.

Tangent: I suppose one could build a redundant serial console solution
by having duplicate conservers and serial concentrators/cabling setups,
one attaches consoles to ttya and one attaches to ttyb. In a fashion,
Console-HA... for that occasion when you fry a serial port or trash your
primary console infrastructure. Overkill for most environments. :)

-dolan