> From: Ted Bullock <tbullock@comlore.com>
> Date: Tue, 13 Oct 2026 09:27:19 -0600
> Content-Type: text/plain; charset="utf-8"
> 
> Hiya folks,
> 
> In my pursuit of killing gremlins in sparc64 I made another discovery.
> 
> I think I've finally tracked down what was starting the console problem on
> my Sun Blade 100. I was working on the Radeon KMS handoff and testing going
> into and out of X, and occasionally getty would start failing and I would
> lose access to the graphics device from my X session.
> 
> With the default keyboard configuration, X and getty are reading from the
> same terminal input queue. X uses /dev/ttyD0, and getty uses /dev/console,
> which forwards to that same terminal. So they are competing for the input,
> rather than each getting a separate copy of keypresses.
> 
> X puts the keyboard into raw mode. The number row 3 key then produces the
> scan code 0x04, rather than the character 3. If getty gets that byte
> instead of X, it interprets it as EOT and exits.
> 
> I was able to reproduce that by briefly pausing only X's reader and
> pressing the key. The getty trace showed a successful one byte read,
> followed by exit(1). I hadn't killed getty or revoked the console to
> make it happen. Normal typing didn't reliably reproduce it, only when
> I would press 3 and only sometimes at that because sometimes X would
> correctly receive the keypress.
> 
> After that exit, the replacement getty failed with login_tty: Operation
> not permitted. Init then kept restarting it and resetting the device
> permissions for the display through fbtab, which explains why some of
> my graphical applications were subsequently reporting permission errors.
> 
> Looking back through the history, the old sparc64 X README explicitly
> said to disable console getty when running xdm, and later xenodm. That
> warning was still there before the README was removed in 2020. It didn't
> explain this particular failure, but it clearly described a restriction
> on running the two together.
> 
> I can't say which input caused each of the earlier occurrences, since I
> didn't have a trace of their first exit. But this does identify a way that
> ordinary keyboard input can start the problem on sparc machines running x.
> I thought it was worth following up with that explanation, especially after
> the earlier getty error handling discussion.

This is a known issue and simply not supported.  You either have to

  Enable "console" and disable all the other potential console
  devices.  This means the getty always runs on the console picked by
  OpenFirmware, and moves from the glass console to the serial console
  when you unplug the kernel.

or

  Disable "console" and enable all the other potential console
  devices.  This means that you always have a getty running on all
  possible console devices.