Aorus X399 gaming 7 new bios update

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.

---------- system specs ----------
hardware:
1950x
Aorus x399 gaming 7
2 sticks of Vcolor 2400Mhz ECC memory ( 16G * 2 )
gtx750 + rx550

OS: Antergos
Kernel: x86_64 Linux 4.17.6-1-ARCH

1 Like

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

2 Likes

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.

Device 28:00.2 is:

This Call Trace is repeated several times over:

Jul 19 00:31:17 jupiter kernel: INFO: task systemd-udevd:640 blocked for more than 120 seconds.
Jul 19 00:31:17 jupiter kernel:       Tainted: P           O      4.17.8-1-ck #1
Jul 19 00:31:17 jupiter kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Jul 19 00:31:17 jupiter kernel: systemd-udevd   D    0   640    604 0x80000124
Jul 19 00:31:17 jupiter kernel: Call Trace:
Jul 19 00:31:17 jupiter kernel:  ? __schedule+0x6cd/0xe40
Jul 19 00:31:17 jupiter kernel:  ? _raw_spin_unlock_irqrestore+0x20/0x40
Jul 19 00:31:17 jupiter kernel:  ? preempt_count_add+0x68/0xa0
Jul 19 00:31:17 jupiter kernel:  schedule+0x32/0xc0
Jul 19 00:31:17 jupiter kernel:  __sev_do_cmd_locked+0xd4/0x260 [ccp]
Jul 19 00:31:17 jupiter kernel:  ? wait_woken+0x80/0x80
Jul 19 00:31:17 jupiter kernel:  ? 0xffffffffc10d4000
Jul 19 00:31:17 jupiter kernel:  __sev_platform_init_locked+0x2f/0x80 [ccp]
Jul 19 00:31:17 jupiter kernel:  ? _raw_write_unlock_irqrestore+0x1c/0x30
Jul 19 00:31:17 jupiter kernel:  sev_platform_init+0x1d/0x30 [ccp]
Jul 19 00:31:17 jupiter kernel:  psp_pci_init+0x40/0xe0 [ccp]
Jul 19 00:31:17 jupiter kernel:  ? 0xffffffffc10d4000
Jul 19 00:31:17 jupiter kernel:  sp_mod_init+0x16/0x1000 [ccp]
Jul 19 00:31:17 jupiter kernel:  do_one_initcall+0x46/0x1f2
Jul 19 00:31:17 jupiter kernel:  ? free_unref_page_commit+0x66/0xf0
Jul 19 00:31:17 jupiter kernel:  ? kmem_cache_alloc_trace+0x182/0x1d0
Jul 19 00:31:17 jupiter kernel:  ? do_init_module+0x22/0x210
Jul 19 00:31:17 jupiter kernel:  do_init_module+0x5a/0x210
Jul 19 00:31:17 jupiter kernel:  load_module+0x2432/0x2990
Jul 19 00:31:17 jupiter kernel:  ? vmap_page_range_noflush+0x26c/0x350
Jul 19 00:31:17 jupiter kernel:  ? __se_sys_init_module+0x10c/0x170
Jul 19 00:31:17 jupiter kernel:  __se_sys_init_module+0x10c/0x170
Jul 19 00:31:17 jupiter kernel:  do_syscall_64+0x5b/0x170
Jul 19 00:31:17 jupiter kernel:  entry_SYSCALL_64_after_hwframe+0x44/0xa9
Jul 19 00:31:17 jupiter kernel: RIP: 0033:0x7f0f199aaf3a
Jul 19 00:31:17 jupiter kernel: RSP: 002b:00007ffe805fc5f8 EFLAGS: 00000246 ORIG_RAX: 00000000000000af
Jul 19 00:31:17 jupiter kernel: RAX: ffffffffffffffda RBX: 00005633708f3320 RCX: 00007f0f199aaf3a
Jul 19 00:31:17 jupiter kernel: RDX: 00007f0f19247ecd RSI: 000000000002c548 RDI: 00005633711532b0
Jul 19 00:31:17 jupiter kernel: RBP: 00007f0f19247ecd R08: 0000000000000007 R09: 0000000000000006
Jul 19 00:31:17 jupiter kernel: R10: 00005633708cd010 R11: 0000000000000246 R12: 00005633711532b0
Jul 19 00:31:17 jupiter kernel: R13: 000056337091e920 R14: 0000000000020000 R15: 00005633708f3320
Jul 19 00:33:20 jupiter kernel: INFO: task systemd-udevd:640 blocked for more than 120 seconds.
Jul 19 00:33:20 jupiter kernel:       Tainted: P           O      4.17.8-1-ck #1
Jul 19 00:33:20 jupiter kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.

There is some chatter related to SME/SVM CCP code on the LKML recently
https://lwn.net/Articles/758560/

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

[ 1351.303225] INFO: task systemd-udevd:542 blocked for more than 120 seconds.
[ 1351.303231]       Not tainted 4.18.0-1-MANJARO #1
[ 1351.303233] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 1351.303235] systemd-udevd   D    0   542    512 0x80000124
[ 1351.303238] Call Trace:
[ 1351.303249]  ? __schedule+0x29b/0x8b0
[ 1351.303251]  ? _raw_spin_unlock_irqrestore+0x20/0x40
[ 1351.303255]  ? preempt_count_add+0x68/0xa0
[ 1351.303257]  schedule+0x32/0x90
[ 1351.303266]  __sev_do_cmd_locked+0xd7/0x270 [ccp]
[ 1351.303270]  ? netlink_broadcast_filtered+0x142/0x400
[ 1351.303272]  ? wait_woken+0x80/0x80
[ 1351.303278]  sev_do_cmd+0x2a/0x40 [ccp]
[ 1351.303281]  ? 0xffffffffc04e0000
[ 1351.303286]  sev_get_api_version+0x34/0xa0 [ccp]
[ 1351.303290]  ? sp_get_psp_master_device+0x63/0x80 [ccp]
[ 1351.303295]  psp_pci_init+0x43/0x230 [ccp]
[ 1351.303297]  ? 0xffffffffc04e0000
[ 1351.303302]  sp_mod_init+0x16/0x1000 [ccp]
[ 1351.303305]  do_one_initcall+0x46/0x1f5
[ 1351.303310]  ? free_unref_page_commit+0x70/0xf0
[ 1351.303313]  ? kmem_cache_alloc_trace+0x181/0x1d0
[ 1351.303317]  ? do_init_module+0x22/0x210
[ 1351.303319]  do_init_module+0x5a/0x210
[ 1351.303321]  load_module+0x2295/0x24b0
[ 1351.303326]  ? vmap_page_range_noflush+0x243/0x320
[ 1351.303329]  ? __se_sys_init_module+0x10c/0x170
[ 1351.303331]  __se_sys_init_module+0x10c/0x170
[ 1351.303335]  do_syscall_64+0x5b/0x170
[ 1351.303337]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 1351.303340] RIP: 0033:0x7f0eb14a2f3a
[ 1351.303341] Code: Bad RIP value.
[ 1351.303348] RSP: 002b:00007ffde5dda238 EFLAGS: 00000246 ORIG_RAX: 00000000000000af
[ 1351.303350] RAX: ffffffffffffffda RBX: 0000559fe9faef60 RCX: 00007f0eb14a2f3a
[ 1351.303351] RDX: 00007f0eb0d3fecd RSI: 000000000002d350 RDI: 0000559fea010120
[ 1351.303352] RBP: 00007f0eb0d3fecd R08: 0000000000000006 R09: 0000000000000005
[ 1351.303353] R10: 0000559fe9fa0010 R11: 0000000000000246 R12: 0000559fea010120
[ 1351.303354] R13: 0000559fe9fa85c0 R14: 0000000000020000 R15: 0000559fe9faef60

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.

I think they might catch some flack on social media for that last one.

I was able to flash F10 on my board and compile a kernel with CONFIG_CRYPTO_DEV_SP_PSP=n. I no longer get systemd-udeved crashes.

1 Like

Thanks for that, just built a system with a 1950x and X399 DESIGNARE EX and this solved the systemd-udevd hangs.

After F10, I’m interested to know if the PCIex4 2.0 from the chipset has it’s own group?

This not only affects threadripper, having trouble with my 1800X system as well.

This also affects x470 boards with AGESA 1.0.0.4.

https://bugs.archlinux.org/task/59483