Keyboard fails to activate BIOS function occasionally.
Keyboard fails to activate BIOS function occasionally.
I've been facing an odd problem with the TUF x570 plus lately. When I power it on and press F2 while using a keyboard connected to PS/2, the BIOS sometimes functions correctly but other times it completely skips all key inputs and jumps straight into Windows. I've tested the BIOS key on a USB port and it works every time, only on PS/2 it fails. Once the system boots into Windows, the PS/2 port works perfectly—I can type normally. There was also an instance where the machine entered safe mode during memory initialization, and it wouldn't respond to the PS/2 F1 key. This seems strange given that the board usually boots without issues and stays on NumLock until the end, even when the keyboard doesn't trigger BIOS. Despite this, all three lock lights flash briefly at startup before only NumLock activates for the rest of the boot process, even if the keyboard fails. It contradicts the usual behavior where USB tends to cause initialization problems and PS/2 remains reliable.
There doesn't appear to be a clear pattern about when the BIOS key works versus when it doesn't. Once it stops working, it usually stays unresponsive for several boot cycles—sometimes even after completely shutting down the system. I suspect two likely causes: a possible BIOS bug or an issue where the keyboard is drawing more power than the port can supply, preventing full initialization. The other possibility is an obscure error in the keyboard's microcontroller, which seems unlikely but can't be ruled out.
The straightforward fix would be to use a USB keyboard for BIOS access, though this adds extra steps. If this is indeed a BIOS issue, I hope Asus or AMI releases an update for the TUF x570 plus. This situation is unusual and I'm curious to hear if anyone else has encountered it.
Info: Motherboard model TUF x570 plus (WiFi), BIOS version 4022 (latest). Keyboard: IBM model M (1390131). CPU: r7-3700x (both CPU and memory overclocked, stable in tests).
Edit: The board uses the Nuvoton NCT6798D-R SuperIO controller. If this helps, someone might know about problems with the 8042 chip in that specific model.
Occasionally things go wrong in computers. It might be a connection issue. The cable or another part could be the problem.
Other possibilities are even more problematic. "Sometimes" often signals a brief short or loss of connection, usually caused by a tiny crack in the wire with a minuscule gap between its sections. This gap is so small it can be sealed by heat, allowing the connection to function intermittently.
You might want to examine the traces and components near the port and the S/IO chip for any obvious problems. If you don’t see anything, testing a different PS/2 keyboard could help determine if the issue is with the hardware. If it’s a tiny defect, visibility may be limited. Have you considered any possible alternatives?
Makes sense, would you suggest adjusting the area around the port or reworking the superIO chip? I think the superIO would be more risky because losing it would affect temps, fan, port80, serial and ps/2. Also, since ps/2 boards need detection before the 8042 activates, and historically BIOS handled that only at startup, it seems Windows might bypass the BIOS and directly access the chip. That could explain why it works once Windows is running—it re-initializes the keyboard after the i8042prt driver loads. I’m still more inclined to a BIOS issue, as similar behavior can happen on a restart, even after intense gaming. If the keyboard doesn’t trigger BIOS, it won’t function in tools like Memtest86 either, which uses a simpler KBC driver and likely depends on BIOS for hardware handling. In Windows, the keyboard initializes clearly once the OS loads, indicated by flashing lock lights and returning numlock to normal. I’ll test other ps/2 keyboards and check Microsoft forums for more insight on the i8042prt driver.
It's a rare issue I'd investigate before assuming it's a problem. I'd test it under different conditions—run it at full speed and at low speed—to check for consistent performance. Another approach could be using a ps/2-usb adapter to determine if the problem lies with the device or the connection. They're outdated and inexpensive, so it might be worth checking that first.
It appears to be a rare issue that might have been caught during manufacturing. The risks associated with reflowing make me cautious, yet obtaining an RMA for such a minor problem seems unnecessary. I’d still like to report it to Asus so a BIOS engineer can review the code for any potential issues. Since PS/2 isn’t commonly used, it’s unlikely many will encounter this. I plan to test it on another board after rendering completes, allowing me to power down and swap the board. I currently have a passive USB adapter that works with my laptop, but it won’t connect to this keyboard because the keyboard I’m using is from 1986 and lacks USB support. I might use an active PS/2-to-USB converter with my laptop occasionally, but it would be inconvenient to disconnect when switching devices. I could also attempt a manual BIOS rollback to check for problems in the latest BIOS, though this would be difficult as Asus doesn’t support software-based rollback—I’d need to physically adjust the SPI header, which would be very troublesome.