0

I've installed Ubuntu 16.04 x64 server on Intel NUC5CPYH (8GB RAM Kinston KVR16LS11/8 + 120GB SSD Kingston KC400). When I boot/reboot the server it randomly freezes at different steps and, say 1 out of 4 times, it boots properly and show the login. I've run RAM test from the LiveUSB key, but it seems there are no errors. I've also tried to install x86 architecture but the issue still holds.

The server is installed on the 4th logic partition of the only disk, after Windows 10 (which boots properly every time), a 1GB swap, another small ext4 partition.

When it boots correctly, I've been able to use proficiently both lan and wlan connection, thus is does not seem a problem related to the network adapters driver. I've also run successfully xfce environment.

Please, do you have any suggestion?

Jacopo Filippo
  • 31
  • 1
  • 5

2 Answers2

3

Got it. I've found the following post on a known bug on Ubuntu 15.10 (kernel 4.2). Mine is Ubuntu 16.06 with kernel 4.4, and I upgraded Intel BIOS to 0054 (mar 2016). https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1521749

Briefly, the following solve the issue: BIOS > Boot > Boot Configuration > OS Selection > set Linux. Then, I've booted/rebooted many many time, no more freezing.

Jacopo Filippo
  • 31
  • 1
  • 5
2

You should post your kernel version please! Kernel versions can change with significant effects during the course of a release. BTW I don't think 32-bit sounds likely to provide a workaround, for the problem you describe.

On some kernels before 4.5, we had to blacklist the dw_mac module to avoid always hanging at boot time. I only remember this happening with 4.4, but Ubuntu users have seen it on kernels with lower version numbers. Or apparently blacklisting pinctrl_cherryview is enough. Other users suggested that setting the OS to "Linux" in the firmware menu worked around it. However Linux intends to work on identical systems to Windows; as a firmware setting it's just as likely to break stuff over time.

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1529353

The bug also suggests it's not entirely deterministic. That sounds very much like your issue.

Second known issue

I think over a wider range of kernels, many but not all users (not me!) are reporting that they have to boot with the option intel_idle.max_cstate=1, to avoid a complete lockup at random intervals.

https://bugzilla.kernel.org/show_bug.cgi?id=109051

It sounds like you haven't encountered this, but maybe you didn't use the system for long enough. So you might start noticing this problem once you've worked around the first one.

Everything else

There was a third issue with hanging at reboot/shutdown time. It's not happened to me recently, but unfortunately I'm not sure what the resolution was.

If you ask Ubuntu for help they may blame an outdated BIOS and tell you to upgrade it if it's not already the latest version. I don't think there's a specific reason to try it here, I'm just mentioning it.

Personally I've been trying to run GNOME Shell on this hardware and the graphics haven't been stable enough either. (I've now disabled hardware acceleration with Option "DRI" "off" and Option "AccelMethod" "none"; it's better but I haven't used it very long and it's not usable with GNOME Shell). GNOME Shell isn't particularly fancy or new, so I just don't feel the graphics are safe if acceleration is left enabled. XFCE itself is less likely to trigger problems and would be usable without acceleration. Look out for graphics crashes, particularly in case you mistake it for a kernel-level crash.

sourcejedi
  • 448
  • The issue seems to be BIOS related, as I post as follow. Thanks for help. – Jacopo Filippo May 19 '16 at 08:24
  • 1
    No upvote? :-P. As I say, I would be wary about blaming the BIOS when a Linux specific hack makes it go away. Kernel 4.5 fixes the issue on my machine without BIOS settings, and this is the approach preferred by the Linux developers in general. – sourcejedi May 19 '16 at 10:56
  • 1
    Looking at the commit that fixes it, it does look like this is a hardware "quirk" where the firmware interface has to be worked around. However I'd give you 50% odds the firmware "fix" just stops Linux detecting that hardware. I.e. that either pinctrl_cherryview or dw_dmac does not get loaded after the BIOS setting change, e.g. see lsmod | grep pinctrl_cherryview. Bug link: https://bugzilla.kernel.org/show_bug.cgi?id=101271#c8 Patch link: http://www.spinics.net/lists/dmaengine/msg07501.html – sourcejedi May 19 '16 at 10:56