The console login prompt is provided through the @svc:/system/console-login:default@ service. This service starts the "ttymon(1M)":https://illumos.org/man/1M/ttymon 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)":https://illumos.org/man/1M/sttydefs 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: <pre> $ 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 </pre> 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: <pre> $ 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 </pre> 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 an already installed system should see no change as a result of this update will not clobber them: to the defaults: <pre> SUNWcs.mf 471:file path=etc/ttydefs group=sys preserve=true </pre> 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.