Early firmware lagging

BIOS and bootloaders seem to lag when certain expansion cards are inserted. The same issue apparently existed on the FW13, where the DP expansion card appeared to be the culprit. Thusfar the 250GB expansion card is giving me the same issues, where keypresses take 1-2 seconds each in both the BIOS and GRUB. Removing the card resolved all issues immediately (no reboot required to take effect).

Additionally, I noticed this does not only affect keypresses themselves. I went ahead to torture myself by very carefully entering my 20ch+ password into GRUB to decrypt my boot partition, which after half an hour I had to abort as it was taking too long. After the expansion card removal this process only took up to 10 seconds, which leads me to believe the cards are hammering the CPU/IO somehow.

Anyone else having similar issues on the FW16 as well?

I know this was posted a while ago but, yes, I noticed this almost immediately when I first turned on my FW16. It is not fixed in the current latest firmware 3.03.

The first thing I did after running MemTest86 was enter the BIOS and saw lag and dropped key inputs. I noticed the computer came with 3.02 firmware, so ran the 3.03 update from a thumb drive. Running the update took over 30 minutes, which seems suspicious. The gear animation during the update seemed to lag in a similar way. At about 50% progress, something changed (some bus reset?), the rest of the update finished instantly, and there was no lag in the BIOS menu any more after rebooting.

I then installed Linux, but made a configuration error, so reinserted my thumb drive during the Framework splash screen. This caused the lag to reappear while in Grub. (Both key press and key release events were being dropped.) When I booted into the Linux installer, it could no longer detect the Ethernet expansion card (port 2), only the WiFi card. The NVMe devices were also being enumerated in a different order than before.

I do have the DP card in port 1, so when I noticed the lag happening, I tried pulling it and that seemed to fix things. But I don’t know if it is actually the DP card’s fault since the problem started after plugging in a thumb drive to a USB-A card in port 5.

When this bug is happening it seems like something is causing a bus stall on a timed interval, rather than at random, or in response to inputs. I haven’t had time to see if I can create a reproducible test case yet; I was not planning to have to troubleshoot my new laptop’s firmware…