Project

General

Profile

Bug #12706

Updated by Joshua M. Clulow about 2 years ago

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.

Back