So far, so good. Though, I am still at the SATA 1-4.
One other thought was, maybe this is about the CPU lanes. So, let's see if that has some merit.
The CPU itself has 28 lanes.
Lane users:
- GTX 1080 Ti Strix, that alone is 16 lanes
- The M.2? Perhaps 4 lanes
- AE-9: Its slot is using 2 lanes.
- DMI 3.0, for PCH-CPU: 4 lanes
That is 26 so far. I wonder if there would be other spenders.
[edit 2020-03-18] Now, this bit is interesting:
https://www.hardwarezone.com.my/feature-heres-all-you-need-know-about-intels-new-x299-platform
It would say that the rest of the things go to the chipset. So, SSDs should not clog the CPU. That is good. But being so close to the lane limit is scary!
[edit 2020-03-20] Meanwhile, I am at stable four drives now. Yippee!! I will keep going.
One other thought was, maybe this is about the CPU lanes. So, let's see if that has some merit.
The CPU itself has 28 lanes.
Lane users:
- GTX 1080 Ti Strix, that alone is 16 lanes
- The M.2? Perhaps 4 lanes
- AE-9: Its slot is using 2 lanes.
- DMI 3.0, for PCH-CPU: 4 lanes
That is 26 so far. I wonder if there would be other spenders.
[edit 2020-03-18] Now, this bit is interesting:
https://www.hardwarezone.com.my/feature-heres-all-you-need-know-about-intels-new-x299-platform
It would say that the rest of the things go to the chipset. So, SSDs should not clog the CPU. That is good. But being so close to the lane limit is scary!
[edit 2020-03-20] Meanwhile, I am at stable four drives now. Yippee!! I will keep going.
jberkpc wrote:
I had a very similar issue after updating Kubuntu 18.04. After the update when I attempted to reboot I got stuck in a reboot loop. If I shut the computer down, I could reboot to Windows fine, so I went back to Kubuntu to see what packages I had installed during the update. The package that stood out to me was an Intel microcode update. I rolled back the microcode update to the previous version and locked it.
The reboot issues went away! You are using an older version of Ubuntu, 20.04 is now out and I don't think 16.04 is still supported so you might not be able to get the previous version of the microcode so maybe you can just remove the Intel microcode package completely.
It's not the first time I have had problems with Intel microcode updates and it seems to be a matter that it works for some CPU's and not others.
That is an interesting angle worth exploring. Date-wise, my problem did start after the installed version of the microcode was produced.
$ dmesg | grep microcode
[ 0.000000] microcode: microcode updated early to revision 0x2000064, date = 2019-07-31
[ 0.943145] microcode: sig=0x50654, pf=0x4, revision=0x2000064
[ 0.943269] microcode: Microcode Update Driver: v2.2.
$ apt list | grep microcode
amd64-microcode/xenial-updates,xenial-security,now 3.20191021.1+really3.20180524.1~ubuntu0.16.04.2 amd64 [installed,automatic]
intel-microcode/xenial-updates,xenial-security,now 3.20191115.1ubuntu0.16.04.2 amd64 [installed]
microcode.ctl/xenial 1.18~0+nmu2 amd64
However, I don't have the option to use it or not. Is it possible that the microcode is unusable with my system anyway, so it is not really used?
BIOS-wise, now I went back to the beginning, and will see what that brings. Do you see anything suspicious in this list?
martine-dee wrote:
That is an interesting angle worth exploring. Date-wise, my problem did start after the installed version of the microcode was produced.$ dmesg | grep microcode
[ 0.000000] microcode: microcode updated early to revision 0x2000064, date = 2019-07-31
[ 0.943145] microcode: sig=0x50654, pf=0x4, revision=0x2000064
[ 0.943269] microcode: Microcode Update Driver: v2.2.$ apt list | grep microcode
amd64-microcode/xenial-updates,xenial-security,now 3.20191021.1+really3.20180524.1~ubuntu0.16.04.2 amd64 [installed,automatic]
intel-microcode/xenial-updates,xenial-security,now 3.20191115.1ubuntu0.16.04.2 amd64 [installed]
microcode.ctl/xenial 1.18~0+nmu2 amd64
However, I don't have the option to use it or not. Is it possible that the microcode is unusable with my system anyway, so it is not really used?
BIOS-wise, now I went back to the beginning, and will see what that brings. Do you see anything suspicious in this list?
It looks like you are using the unattended-upgrade package which automatically updates any security packages so if you roll back the Intel microcode to the previous version it will probably just update it again.
I uninstall that package when I install Kubuntu. because I update 5 days a week. and want more control of updates .
According to this you can pass a kernel command line parameter that disables the microcode updates but that's above my pay grade
https://wiki.debian.org/Microcode#Working_around_boot_problems_caused_by_microcode_updates.
I t looks like I was wrong about updates to 16.04, it looks like it's supported until some time in 2021.
All I know is rolling back to the previous version on the microcode solved my problems which are just like yours and I've updated my Kubuntu install many times including numerous kernel updates since without issue.
I'm running a 10920X with the RE6E motherboard.
Best of Luck.
