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 specs

The machine is a brand new Lenovo Yoga 710 15"

Intel i7-6500 CPU @ 2.50 GHz, 2601 Mhz, 2 Cores, 4 Logical Processors
SMBIOS Version 2.8
16.0 GB DDR4 Ram
256 MB SSD

isolating to linux kernel (?)

I've seen the same problems on both

  • archlinux-2016.08.01-dual.iso
  • ubuntu-gnome-16.04.1-desktop-amd64.iso

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
  • RIP kmem_cache_alloc
  • RIP kmem_cache_alloc_trace

I've seen some of the same stack traces several times for these errors:




Linux also keeps promising that it's fixing the problem

Fixing recursive fault but reboot is needed!

I wish..

intel ucode

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?


Additional 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.


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 maxcpus

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

Although 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.



So using 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 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?

  • Have you tried installing the nvidia driver for your NVIDIA GeForce 940MX? – Paul Nordin Aug 25 '16 at 0:55
  • No I haven't -- I might be able to get the arch usb stick booted again, but it's kind of tricky. Is there any way to pass in a kernel option in the boot script to disable the gpu temporarily to test this? (I did try nomodeset and nouveau.mode=0 -- not sure if that's similar) – tmsimont Aug 25 '16 at 2:17
  • hmm I looked into the linux kernel parameters docs and found maxcpus -- I set it to 1 and the problem goes away... But now I can only use one procesor? :( – tmsimont Aug 25 '16 at 2:39
  • That is strange. I still suspect the underlying issue is related to nouveau. Try the parameters nomodeset nouveau.modeset=0 together and if that doesn't work, try nomodeset i915.modeset=0 nouveau.modeset=0 – Paul Nordin Aug 25 '16 at 3:22
  • 1
    I would try booting Ubuntu again just to throw a different kernel version into the mix. Make sure to enable legacy mode in the BIOS first or at least, disable secure boot and fast boot or anything like that if you haven't already. – Paul Nordin Aug 25 '16 at 3:41

Turns out the issue was i2c_hid

This 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_hid

Although 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.

  • 3
    Thanks very much for sharing you finding! Based on your information I found that disabling hid_sensor_hub is sufficient and the touchscreen is also usable (see my answer below for more details). – jiakai Oct 22 '16 at 9:21

All of these errors look like ones I've seen with bad kernel modules.

There's someone on ubuntuforums that claimed they got ubuntu to boot on a 710-14ISK by disabling acpi (add acpi=off to the kernel options). https://ubuntuforums.org/showthread.php?t=2329448

Another customer on lenovo's forums said they had trouble booting fedora 24 and traced the problem to a piece of broadcom firmware: https://forums.lenovo.com/t5/Linux-Discussion/Yoga-710-How-to-install-Linux/td-p/3361544

Try blacklisting the broadcom and nouveau modules (leave them unclaimed) and boot with acpi off. I had similar logs when I had an ill-behaved ralink module in an old acer: blacklisting the module let me boot and stopped the kernel panics, but left me without wifi.

PS. I'd put all of this in a comment, but I don't have enough reputation to comment (sorry).

  • I think you're on to something. acpi=off made the error go away, but it also disables my keyboard. It looks there's more granular options with acpi, so I'll see if I can make the errors stop, while keeping my keyboard :) – tmsimont Aug 26 '16 at 12:23
  • 1
    hmm, maybe just disabling some parts of acpi is the way to go. There's quite a few options, but i would try acpi=ht first. help.ubuntu.com/community/BootOptions (look under Common Kernel Options) or for a more comprehensive list: kernel.org/doc/Documentation/kernel-parameters.txt – Schives Aug 27 '16 at 22:32
  • nolapic worked for me and I'm able to boot, but I can then only access one of my CPU's. I'm trying to use this laptop for developing OpenMP programs, so having only 1 CPU working isn't OK. It seems that there's just something terribly wrong in how the kernel is trying to use my multiple CPU's. The fact that nolapic "fixes" boot may only be coincidentally due to the fact that it limits the kernel to 1 CPU – tmsimont Aug 28 '16 at 17:02
  • one other note -- this does work fine in windows 10. Is there anything I can pull up in windows to learn more about anything that the windows kernel does with the CPU's that I might be able to replicate in linux? – tmsimont Aug 28 '16 at 17:06

I experienced similar problems with recent kernels (4.7.x to 4.8.2) on my yoga710 with i5-6200U. Disabling i2c_h2d works for me. I also found that linux-lts (currently 4.4.25) seems to work well, including the touchpad and the touchscreen.

Edit: by experimenting with the driver code, I found that this is indeed caused by the hid_sensor_hub driver, so blacklisting it solves the problem and the touchscreen is also usable. Surely disabling it makes the sensors (such as the accelerometer) unrecognized. I tried to fix the driver; however I have not yet figured out a way.


You need a Linux kernel of version 4.4 or later for Skylake support. Check out the following link at the Arch Linux wiki. https://wiki.archlinux.org/index.php/intel_graphics#Skylake_support

  • archlinux-2016.08.01-dual.iso contains 4.6.4, so that should work – maxf Aug 25 '16 at 9:03
  • This is a stupid question but have you run memtest on your computer ? memtest.org – Peter Skarpetis Aug 25 '16 at 9:06
  • 1
    @Peter Not stupid, and yes I did. No memory issues. Also yes maxf is right, I've got 4.6.4 – tmsimont Aug 25 '16 at 11:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.