Bug #12706
openhunt sequence for "console" tty label should start at 115200 baud
0%
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 ofconsole1
, thus putting it in the hunt sequence correctly - Remove the truly ridiculously slow speeds, leaving just
console1
at 9600 andconsole2
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.
Updated by Jason King about 2 years 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).