Asrock Fatal1ty X399 And AMD Threadripper 1950x Issues


Well I got my new PC and installed Manjaro with 2x NVME
(wanted to raid them but meh anyways)

So It seems manjaro is running fine without any real problems but I have these messages

[wolfyrion@WPC ~]$ systemd-analyze
Startup finished in 6.141s (kernel) + 864ms (userspace) = 7.006s

This is the link for the motherboard


Can you post the errors also in text form? Also do you have the latest BIOS on the board?


check if you have put NMVe Raid that AHCI is active in Bios
be careful Raid on Linux is soft Raid not Hardware Raid


Yeap BIOS is up to date…
I dont know how to post all these in text. Is there any log that has all these errors logged?

Also on this thread I found the workaround solution to my problem
(added the “pci=nommconf” to resolve these type of errors)

(page 5)

Hi All, we were able to use an acceptable work around for our set up. We figured out that there is a conflict between Nvidia driver and time out period due to the PEX/PCie sleep state. To get around this turn off ASPM in your BIOS, However…

You also need to disable ASPM in the GRUB

" pcie_aspm=off "

For us we saw this issue using the GTX 1080’s. But this was still technically a workaround and even the BIOS released merely gave a more permanent means of a work around. Nvidia basically just gave us the cold shoulder.

First, I apologize I realized I poorly wrote my last response… I should have explained our exact issue.

Are you talking about the “pci=nommconf” and similar for shutting off the AER reporting? Those workaround are simply a mask covering the issue up in the end all this did was turn off the AER reporting service which is ok for some but ads complexity for others. The AER message we were receiving were due to a conflict between the Nvidia driver attempting to communicate with the video card and timing out due to lack of response because the PCIe was in ASPM L0/L1 (asleep essentially)

In the end the reasoning was due to ASPM being in L0/L1 and taking too long to come live again, which inturn has to communicate with the PEX again and then send data to the Nvidia card. When we disable ASPM permanently via OS GRUB (then in the BIOS only after BIOS update) the ASPM would not drop to L0 so there was no delay due to sleep, thus no time out and no AER reported.

Technically it’s a workaround solution, and why all of a sudden we started seeing it I’m not 100% sure, whether it’s from the 1080 drivers or maybe a Intel microcode change we’re not sure.

I found also another answer that he is saying that

Links states dropping to PCIe 1.1 is standard practice of newer GPUs and they only do this while not under load, when under load they ramp back up to full link state
AFAIK there is no way to change this behaviour

Well even with that it needs 7sec to boot

[wolfyrion@WPC ~]$ systemd-analyze
Startup finished in 5.910s (kernel) + 873ms (userspace) = 6.784s                                                                                                                                                            
[wolfyrion@WPC ~]$ systemd-analyze blame                                                                                                                                                                                    
           353ms systemd-modules-load.service                                                                                                                                                                               
           194ms dev-nvme0n1p1.device                                                                                                                                                                                       
           128ms systemd-fsck@dev-sdc1.service                                                                                                                                                                              
           127ms mnt-ROMS.mount                                                                                                                                                                                             
           111ms mnt-STEAM.mount                                                                                                                                                                                            
           111ms systemd-fsck@dev-sdb2.service                                                                                                                                                                              
           107ms systemd-fsck@dev-sda1.service                                                                                                                                                                              
            98ms udisks2.service                                                                                                                                                                                            
            83ms systemd-journal-flush.service                                                                                                                                                                              
            78ms upower.service                                                                                                                                                                                             
            74ms systemd-udev-trigger.service                                                                                                                                                                               
            65ms ModemManager.service                                                                                                                                                                                       
            53ms systemd-journald.service                                                                                                                                                                                   
            53ms mnt-EMU.mount

Well thats all for now about my research on these errors…


dmesg is your friend. Read more about it here and here.


I did dmesg > boot_messages but I cant get these msgs in the log


Just to chime in my 1950x and gtx1070, asrock x399 pro gaming and it has the same boot text.