Mark Kettenis <mark.kettenis@xs4all.nl> wrote:

> > 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.

Yep.

There are two ways the console works, it depends upon architecture.
On sparc64 and some other architectures "console" is the architectural
console.  On others, it is a "pointer" to the real console.

Playing with sessions will not solve it.  The proposed diff just
moves the problem forward because it is still the same tty.