illumos gate

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.