Project

General

Profile

Bug #12706

hunt sequence for "console" tty label should start at 115200 baud

Added by Joshua M. Clulow 2 months ago. Updated 2 months ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
cmd - userland programs
Start date:
Due date:
% Done:

0%

Estimated time:
Difficulty:
Medium
Tags:
Gerrit CR:

Description

The console login prompt is provided through the svc:/system/console-login:default service. This service starts the ttymon(1M) program, which manages the tty for the console whether it's the workstation console or a serial device. For a serial device, this program will set the baud rate (and other parameters) by looking at the /etc/ttydefs file, which is managed by the sttydefs(1M) command.

For the primary console login (i.e., whatever device is known as /dev/console, generally determined by the console boot parameter) this service will default to using the "console" tty label from /etc/ttydefs. In the default copy of /etc/ttydefs file that we ship from the gate, the console label operates at 9600 baud:

$ sttydefs -l console

--------------------------------------------
console:9600 hupcl opost onlcr:9600::console
--------------------------------------------

ttylabel:       console
initial flags:  9600 hupcl opost onlcr
final flags:    9600
autobaud:       no
nextlabel:      console

Additionally, there appears to be a mistake here: ttymon supports a "hunt sequence" of multiple labels, and will switch between them on a serial break. In this case, the nextlabel is explicitly set to console which means the hunt sequence only includes this entry. The reason this appears to be a mistake is because there are other labels which appear to be intended to form a larger hunt sequence:

$ grep ^console /etc/ttydefs 
console:9600 hupcl opost onlcr:9600::console
console1:1200 hupcl opost onlcr:1200::console2
console2:300 hupcl opost onlcr:300::console3
console3:2400 hupcl opost onlcr:2400::console4
console4:4800 hupcl opost onlcr:4800::console5
console5:19200 hupcl opost onlcr:19200::console

Note in particular that console5 loops back to console.

At present, a sensible modern system will use 115200 baud for its console. Indeed, if the user specifies that speed by passing, say, ttya-mode="115200,8,n,1,-" in the boot parameters, we'll start at that mode and then clobber it with 9600 baud once ttymon starts. As a first cut at fixing this, we should:

  • Make console operate at 115200 baud
  • Give console a next label of console1, thus putting it in the hunt sequence correctly
  • Remove the truly ridiculously slow speeds, leaving just console1 at 9600 and console2 at 19200

For extra credit we could explore what "autobaud" will do on a modern system, as that might be a useful option as well.

Note that this data file is marked preserve=true in the IPS manifest, and thus if the user has made local changes this update will not clobber them:

SUNWcs.mf
471:file path=etc/ttydefs group=sys preserve=true

This will mean somebody for whom 9600 is the correct speed will have a surprise on update, but I suspect in practice that is few if any people.

History

#1

Updated by Joshua M. Clulow 2 months ago

  • Description updated (diff)
#2

Updated by Jason King 2 months ago

If an operator has specified serial console settings in the boot parameters, I think we would want ttymon to start with that config, regardless of what's in /etc/ttydefs. Perhaps it could add that config (if there isn't a matching config in the hunt list already) and start with it when an operator supplies an config?

Traditionally sending a break was also how you dropped into the OBP (on Sparc), and kmdb (when loaded). I'm wondering if the lack of cycling between configs might be deliberate because of that (would there be any undesirable interaction if we add it?).

I'm less sure we want to change the default serial console speed -- Linux and FreeBSD from what I can tell default to 9600, and while anecdotal I've also only encountered 1 device that I can recall that didn't use 9600 (it ran windows server in an embedded manner -- not windows embedded mind you -- and so was quite the oddity in more ways than one).

Also available in: Atom PDF