Here comes a new bios update for gigabyte x399 gaming!!
it is said to support new upcoming threadripper ( 2990x 2950x maybe? )
here are some good and bad news:
good news :
1 iommu grouping is even better, more separation can be seen ( sorry because bugs are so annoying that i reverted back to bios f3g so i have no screenshots here ) but as far as a can tell, usb3 from the cpu are now in its own group, though everything connecting to the chip-set is still in a group?
2 now not only x16 lanes are capable of slicing into x4x4x4x4 mode, it seams that x8 lanes are also getting the ability to slice to x4x4 ( there exists the option, though i haven’t tried since i have no nvme riser cards to try )
bad news:
1 ( this is just an issue, not a huge problem, but … ) the sibling threads on the same core have rearranged, in F3x bios, it have a naming scheme close to Intel’s - that is 0 corresponds to 16, 1 to 17 … etc, but after the update, now core 0 and 1 are sibling threads, 2 and 3 are also sibling threads … etc, so for whatever reason you pinned the thread on core id, you may need to re-examine the configuration to fit your original minds.
2 this is the most annoying one, but updating the bios also causes systemd-udevd to go crazy, it will spilt out errors "systemd-udevd worker terminated by signal 9 " on CPUs, and causes panics in dmesg logs ( marked as tainted ), and causing reboots and poweroff hangs since the systemd gives up waiting for systemd-udevd to stop and issues kills that takes forever.
nah, they aren’t gonna increment the number, they’re gonna increment the Xtreme Computeness ™
Series 1: Thread Ripper
Series 2: SIMD Smasher
Series 3: Process Pulverizer
Series 4: Cache Crusher
Series 5: Bus Blaster
Series 6: IOPs Offender
Series 7: Register Rapist
Check their latest press release for more details on their roadmap
That’s great if a portion of the USB3 are in their own group now. Was one of my major gripes with Threadripper since I believe many X370 boards have a separate grouping for USB and Z370 as well.
This is also the same problem with ASRock 4.80 BIOS on a number of X370 Boards that featureUpdate PinnaclePI-AM4_1.0.0.4 in the changelog.
I have contacted ASRock but they dont seem to have done recent linux testing. On their Windows side everything seemed fine though.
The systemd-udevd-settle timeout issue is related to the ccp driver which initializes the Ryzen PSP (Cryptographic Coprocessor) for Secure Virtual machines and Secure Memory Encryption features.
Kernel version is latest 4.17.8 Stable release. But it equally affects kernels going back months.
But I am as such not clued in how this firmware change ties in to that.
Overall though it’s necessary to revert to the previous firmware as this one features a number of serious stability issues, in my particular case a total regression in RAM stability and a failure to boot on ZFS systems as the udev-settle prevents ZFS mounts from successful loading.
I just built my threadripper box. I am running the 1950x as well as the Gigabyte Designare X399 board.
On the F10 bios I see the same results as you. Lots of systemd-udevd blocking and journalctl -u systemd-udevd is showing device “42:00.2” which is my encryption controller. However why is the log also saying it failed while handling the cpus? At least the stack in dmesg is showing ccp.
Also my stack looks a bit different than yours which has a call to netlink_broadcast_filtered
I tried downgrading the bios one rev but it seems to have stability issues for me where the box fails to boot sometimes and throws some error codes on the board. A restart usually causes it to get past those errors. This is kind of frustrating.
