hunt sequence for "console" tty label should start at 115200 baud
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
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:
consoleoperate at 115200 baud
consolea next label of
console1, thus putting it in the hunt sequence correctly
- Remove the truly ridiculously slow speeds, leaving just
console1at 9600 and
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).