For two years, Intel Baytrail processors have been hanging under Linux. Baytrail is a generation of Atom processors and includes many low-end processors that I think of as Atoms but are called things like Pentium and Celeron. But not all Pentium and Celeron processors. <http://ark.intel.com/products/codename/55844/Bay-Trail> The bug report is <https://bugzilla.kernel.org/show_bug.cgi?id=109051> but started elsewhere. A few days ago, entry 724 (!) in that bug report noted the submission of a kernel patch that strongly reduces the problem. The thread for the patch is interesting: <https://lists.freedesktop.org/archives/intel-gfx/2017-January/117932.html> - the fix doesn't fix all the underlying problems but very significantly improves stability. Perhaps to the point that the instability fades into the background noise of crashes. - the fix slightly cripples power management on these systems but much less than the only known work-around (preventing the use of cstates higher than 1) - this may slow down the search for residual bugs, but how can it be slower than the current process has been? - The fix was already in the kernel for Cherryview processors. I'm not sure what those are: it certainly includes Cherry Trail processors. <http://ark.intel.com/products/codename/46629/Cherry-Trail> - the bug started to become visible in Linux 3.17-rc1 and should be ameliorated in 4.11. What a long horrible run. Most of the life of the chips! I have a number of Atom systems that I never got around to Linuxifying due to fear of this bug and, for some, annoyance with 32-bit UEFI firmware. I will say that I've had a great experience with a netbook with a Celeron N2840 (Baytrail). Perhaps because I don't often play video content with it. Some of these Baytrail systems are still a nightmare for Linux due to non-systematic and undocumented connection of the SoCs to the peripheral circuits. Here's a sample thread for one such system (more than 200 entries!): <https://bugzilla.kernel.org/show_bug.cgi?id=95681>