Summary
ConsoleManager times out after 5s waiting for the F9 console switch. The F9 loop presses {f9} to make MiSTer_Main release the framebuffer and expects the VT to become tty1 (f9ConsoleVT), but it ends on tty2, so the loop never confirms and returns timeout waiting for console switch after 5s.
Source: pkg/platforms/mister/console_manager.go (F9 retry loop ~L139-195).
Sentry
~30 events, ongoing on the current release (2.14.1). Representative occurrence tags:
core=MENUcurrentTTY=tty2expectedTTY=tty1targetVT=3arch=arm, num_cpu=1
Why it's deferred
This is genuine MiSTer runtime/VT-switching behaviour. Diagnosing why F9 lands on tty2 rather than tty1 (and whether it's firmware/timing/version-specific) needs investigation on a real device; a blind code change risks breaking console switching for everyone. Intentionally left at Error level so it stays visible while being investigated.
Possible angles
- Is
tty2 a valid post-F9 state on some MiSTer versions that the verify check (tty == "tty"+f9ConsoleVT) doesn't accept?
- Single-CPU device (
num_cpu=1) — could be a scheduling/timing issue under load where 5s is too tight or the backoff eats the window.
- The initial
chvt priming only runs for the MENU core; verify interaction with targetVT=3.
Split out from the Sentry sweep in #965.
Summary
ConsoleManagertimes out after 5s waiting for the F9 console switch. The F9 loop presses{f9}to make MiSTer_Main release the framebuffer and expects the VT to becometty1(f9ConsoleVT), but it ends ontty2, so the loop never confirms and returnstimeout waiting for console switch after 5s.Source:
pkg/platforms/mister/console_manager.go(F9 retry loop ~L139-195).Sentry
~30 events, ongoing on the current release (2.14.1). Representative occurrence tags:
core=MENUcurrentTTY=tty2expectedTTY=tty1targetVT=3arch=arm,num_cpu=1Why it's deferred
This is genuine MiSTer runtime/VT-switching behaviour. Diagnosing why F9 lands on
tty2rather thantty1(and whether it's firmware/timing/version-specific) needs investigation on a real device; a blind code change risks breaking console switching for everyone. Intentionally left at Error level so it stays visible while being investigated.Possible angles
tty2a valid post-F9 state on some MiSTer versions that the verify check (tty == "tty"+f9ConsoleVT) doesn't accept?num_cpu=1) — could be a scheduling/timing issue under load where 5s is too tight or the backoff eats the window.chvtpriming only runs for the MENU core; verify interaction withtargetVT=3.Split out from the Sentry sweep in #965.