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.machine specsThe machine is a brand new Lenovo Yoga 710 15x64Intel i7-6500 CPU @ 2.50 GHz, 2601 Mhz, 2 Cores, 4 Logical ProcessorsSMBIOS Version 2.8BIOS Mode UEFI16.0 GB DDR4 Ram256 MB SSDisolating to linux kernel (?)I've seen the same problems on botharchlinux-2016.08.01-dual.isoubuntu-gnome-16.04.1-desktop-amd64.isoFor 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 SMPRIP kmem_cache_allocRIP kmem_cache_alloc_traceI've seen some of the same stack traces several times for these errors:rbt_memtype_copy_nth_elementon_each_cpuflusH_tbl_kernel_range__purge_umap_area_lazyum_unmam_aliaseschange_page_attr_set_clrset_memory_rofrob_text.isramodule_enable_rokobject_createkobject_create_and_addload_module__symbol_putkernel_readsys_finit_moduleentry_SYSCALL_64_fastpathkmem_cache_alloc_traceallocate_cgrp_cset_links...sys_writeentry_SYSCALL-64_fastpathLinux also keeps promising that it's fixing the problemFixing recursive fault but reboot is needed!I wish..intel ucodeI 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?EDITAdditional note.The general protection fault messages and lock up detected-type messages typically reference a CPU. I've seen CPU0, CPU1 , CPU2 and 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.EDIT2BIOS mentioned in errorI see this bit of information in some errors:LENOVO 80U01LENOVO YOGA710-1 BIOS OGCN20WW(v1.04) 6/30/2016Not sure if that is helpful to a pro in understanding the issue...EDIT3maxcpus=1I was looking for debugging options in the kernel params documentation and found maxcpusIf 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.EDIT3maxcpus=1 + Gnome = broken againAlthough maxcpus=1 seemed to make the system work with just the 1 CPU, I installed gnome and then ran systemctl enable gdm.serviceNow, when I reboot, I get all of my errors back again, but this time they're all happening on CPU0So it seems that something is still causing a memory violation even with the 1 CPU.EDIT4nolapicSo using nolapic seems to get everything workingBUT 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 intel_idle.max_cstate=0 and 1,2, etc. But this does not fix the boot problem.What else could cause the kernel to fail to utilize my multi-core machine?
Why can't linux kernel boot on my new Intel i7-6500U CPU?
boot;linux kernel;kernel panic
Turns out the issue was i2c_hidThis seems to be some kind of touchpad driver. For some reason, when I disable it, I can still use my touchpad. It could be that the touch screen on the laptop was using this driver, too, because that doesn't work.I don't like to mung up my laptop screen with fingerprints, anyway... So bye bye i2c_hid!I fixed it by adding this to the kernel params:modprobe.blacklist=i2c_hidAlthough nolapic also worked, it disabled all but 1 core in processors. I'd highly recommend to anyone else out there to not use apci=off or nolapic for this reason. Using these options is a nuclear weapon that might make your machine work, but you will lose a lot of performance and/or i/o devices as collateral damage. It's a good starting point to get booted, and then you can pour throught journalctl like I did to analyse the boots that fail.Good luck to those who find this.