Disclaimer
Application version
0.5.7-dev
System version
0.2.8-dev
Device model
JetKVM
Extension model
ATX Power Control
Remote device Hardware
n/a
Remote device OS
n/a
Bug description
This was reported by another user on Discord while exploring the hardware issue with recent ATX extension boards, and I also observed it when experimenting with the extension firmware on a RP2040 development board.
The symptom is that the virtual LEDs (in the JetKVM web UI) intermittently "stick" (i.e. don't update) for a while (ranging from a second or two to maybe a minute or more), then return to normal.
On closer inspection, it turns out that there is a serial console mux that's running all the time (even when the serial console extension is not in use), and it's basically fighting with the ATX (or DC) extension handler over who gets to read from the serial port. Using a tweaked version of the extension firmware that toggles both LEDs every second as a testbed, when in the working state, I see:
2026-04-18T14:50:05Z DBG jetkvm serial Status changed hdd=false pwr=false rst=false service=atx_control
2026-04-18T14:50:06Z DBG jetkvm serial Status changed hdd=true pwr=false rst=false service=atx_control
2026-04-18T14:50:07Z DBG jetkvm serial Status changed hdd=false pwr=false rst=false service=atx_control
2026-04-18T14:50:08Z DBG jetkvm serial Status changed hdd=true pwr=false rst=false service=atx_control
then, all of a sudden, it changes to:
2026-04-18T14:50:09Z TRC jetkvm serial Sending RX data to console broker service="SerialMux reader"
2026-04-18T14:50:09Z TRC jetkvm serial Processing RX data from serial port service="Serial Console Broker"
2026-04-18T14:50:09Z TRC jetkvm serial Emitting RX data to sink (with per-line prefixes) service="Serial Console Broker RX handler"
2026-04-18T14:50:10Z TRC jetkvm serial Sending RX data to console broker service="SerialMux reader"
2026-04-18T14:50:10Z TRC jetkvm serial Processing RX data from serial port service="Serial Console Broker"
2026-04-18T14:50:10Z TRC jetkvm serial Emitting RX data to sink (with per-line prefixes) service="Serial Console Broker RX handler"
2026-04-18T14:50:11Z TRC jetkvm serial Sending RX data to console broker service="SerialMux reader"
2026-04-18T14:50:11Z TRC jetkvm serial Processing RX data from serial port service="Serial Console Broker"
2026-04-18T14:50:11Z TRC jetkvm serial Emitting RX data to sink (with per-line prefixes) service="Serial Console Broker RX handler"
Seems that the serial mux needs to be closed when the ATX or DC extensions need to be able to read from the serial port.
Disclaimer
Application version
0.5.7-dev
System version
0.2.8-dev
Device model
JetKVM
Extension model
ATX Power Control
Remote device Hardware
n/a
Remote device OS
n/a
Bug description
This was reported by another user on Discord while exploring the hardware issue with recent ATX extension boards, and I also observed it when experimenting with the extension firmware on a RP2040 development board.
The symptom is that the virtual LEDs (in the JetKVM web UI) intermittently "stick" (i.e. don't update) for a while (ranging from a second or two to maybe a minute or more), then return to normal.
On closer inspection, it turns out that there is a serial console mux that's running all the time (even when the serial console extension is not in use), and it's basically fighting with the ATX (or DC) extension handler over who gets to read from the serial port. Using a tweaked version of the extension firmware that toggles both LEDs every second as a testbed, when in the working state, I see:
then, all of a sudden, it changes to:
Seems that the serial mux needs to be closed when the ATX or DC extensions need to be able to read from the serial port.