Have a PC that I started building on Saturday, which I’m still building (and preparing for work). Its a 9900x with MSI x870 Tomahawk Wifi board. Latest bios.
Today I plugged an old cheap kb from the 2010s, which was lying on the shelf and collecting dust (need a usb kb to pass the encryption process).
Noticed that Fedora took a few minutes of circle animations just to get to the “Enter passphrase”. But when appeared, didn’t get the input. A few "reset"s later I plugged a second keyboard, and, although the process was still slow, I managed to input the passphrase and continue.
But got stuck on KDE’s enter password screen. Both the KB’s and Mouse’s inputs weren’t registered.
There went another reset. Entered bios. BIOS worked, but felt sluggish (pressing F10 and getting “Save and exit” with two buttons took a second or so just from pressing ← or → on the board).
Finally I unplugged the old KB (maybe its dead or something).
System started to behave more responsive. I passed the encryption, login and all seemed fine. But then I noticed that my wifi is down for some reason (while BT worked fine).
Reboots (ofcourse) did nothing. Only after I shutdown the system and turned it back on, everything started working.
Since this is my first AMD in many years, my question is - is this something, brought by that old KB (honestly, I don’t want to try again), or is it in the “margin of tolerance” how Ryzen/AMD Mobos work?
I chalk it up to the motherboard maker, but an expert can correct me if I’m wrong.
I have noticed on AM5 that fast boot and 1 second timeouts are the default. This does occasionally cause problems, because the UEFI only partially loads USB drivers and hardware to skip steps in the normal boot process.
Once in 20 reboots or so I will have partially broken input on the mouse, requiring I unplug and replug the USB mouse and then it works as if nothing happened. On defaults sometimes the Marvell 10GbE NIC doesn’t have time to initialize, super rare but uber annoying because I only discover it after something fails to access the mapped NAS off it.
I disabled fast boot (so the UEFI doesn’t take shortcuts initializing the USB drivers) and set the UEFI to a timeout of 3 and that seems to prevent nearly all the various random boot annoyances and USB device handoff issues once in Windows.
Probably the keyboard being too old. Sounds weird, but I have seen crazy stuff like that before. I once built a computer and it worked great at my house, took it to a friends and it bluescreened for him non stop. He couldn’t do anything with the PC. Bring it back, works perfect. Stress tests show everything good. Take it back, bluescreens. Finally figured out he was using an old mouse from apparently too long ago and either the hardware or Windows simply did not like it. Bought a new mouse and everything worked perfect.
Thanks. Will definitely disable Fast Boot (for some reason even forgot it existed).
Funny thing is, last year I bought my Odroid x86 sbc, and I remember having a problems on the first boot, where the system was operating relatable to 1fps - I literally saw the BIOS screen draw line by line. And that time it also was a keyboard. But I can’t put my mind on the question of which of the two spare keyboards I have just for some quick initial setup/tweak was used - this one, or the newer one. Starting to get the idea that it was the same board.
Hm. It turns out I now have “The one keyboard to brick them (modern PCs) all”. I wonder if it’s just age, with something literally going to dust and creating a short circuit, or the board’s usb 2.0 controller is “that old”.
Egh. I do have a disassembled Corsair K95, where I need to replace a switch. Maybe it is time to finally buy that switch and resurrect that board.