It' hard to isolate the CPU, I know, but the errors I'm seeing suggest that's the issue.
This is definitely not a malfunctioning/broken hardware problem. I've been running Windows 10 all day for the past several days and this thing is flippin' fast! No crashing. More importantly, I ran Windows memory checker. Memory is all good.
The machine is a brand new Lenovo Yoga 710 15"
x64 Intel i7-6500 CPU @ 2.50 GHz, 2601 Mhz, 2 Cores, 4 Logical Processors SMBIOS Version 2.8 BIOS Mode UEFI 16.0 GB DDR4 Ram 256 MB SSD
isolating to linux kernel (?)
I've seen the same problems on both
For Arch -- the problem was only appearing intermittently at boot from the USB stick. I managed to get Arch installed on a 100GB ext4 partition on the drive. That install has the same issue intermittently (like 90% of the time) during boot. If I get passed the boot, then the issue appears at random after the first couple of terminal commands I execute, eventually causing a complete deadlock.
For Ubuntu -- the USB stick doesn't even boot. I get stopped by these same errors immediately. Deadlock...
So many errors...
The journal is stuffed with memory-related errors whenever this happens, but the key errors I'm seeing are:
General protection fault 0000[#1] PREEMPT SMP
I've seen some of the same stack traces several times for these errors:
rbt_memtype_copy_nth_element on_each_cpu flusH_tbl_kernel_range __purge_umap_area_lazy um_unmam_aliases change_page_attr_set_clr set_memory_ro frob_text.isra module_enable_ro
kobject_create kobject_create_and_add load_module __symbol_put kernel_read sys_finit_module entry_SYSCALL_64_fastpath
kmem_cache_alloc_trace allocate_cgrp_cset_links ... sys_write entry_SYSCALL-64_fastpath
Linux also keeps promising that it's fixing the problem
Fixing recursive fault but reboot is needed!
I also tried installing the
intel-ucode package in my Arch install. I saw in the
dmesg logs that the microcodes were updated, but that unfortunately did not solve my problem.
What could be the issue? How can fix it?
The general protection fault messages and "lock up detected"-type messages typically reference a CPU. I've seen
CPU3 in these messages. It seems like something is causing the CPU's to not get along, like they're all in a deadlock trying to clear out cache memory or something.
BIOS mentioned in error
I see this bit of information in some errors:
LENOVO 80U01LENOVO YOGA710-1 BIOS OGCN20WW(v1.04) 6/30/2016
Not sure if that is helpful to a pro in understanding the issue...
I was looking for debugging options in the kernel params documentation and found
If I set max cpu's to 1, then the problem goes away. So it would seem that the problem is some kind of shared cache memory violation.
maxcpus=1 + Gnome = broken again
maxcpus=1 seemed to make the system work with just the 1 CPU, I installed gnome and then ran
systemctl enable gdm.service
Now, when I reboot, I get all of my errors back again, but this time they're all happening on CPU0
So it seems that something is still causing a memory violation even with the 1 CPU.
nolapic seems to get everything "working"
BUT by using
nolapic, I effectively disable my other CPU and all multithreading in the 1 working CPU.
I'm trying to use this for OpenMP, and after booting with
nolapic, OpenMP and the linux kernel can only find 1 thread, 1 CPU. That sucks!
I also tried
2, etc. But this does not fix the boot problem.
What else could cause the kernel to fail to utilize my multi-core machine?