Please give more details about your issue. May I know the Linux Distribution that you are using? Do you have the UEFI and Legacy boot enable at the same time?
Let me know the NUC model, BIOS version and amount of RAM.
Bear in mind, Intel provides with drivers for Windows® operating systems, for Linux, the drivers are provided with their community. The link below shows which units were already tested with Linux operating systems.
Simply because the drivers for using a NUC (the intel stuff) is already provided by the Linux kernel (mainly commited by Intel) so you dont need any additional drivers.
Also Linux _IS_ officially supported by Intel to be runned on NUCs, just read the releasenotes for lets say the BIOS updates (hint: OpenELEC is a Linux distribution).
Also the bricked NUC due to sleepmode is a hilarious malfunction caused by Intel engineers - which is also proven since BIOS was it version 0038 (for D54250WYK) claims to fix this issue.
Have there been any more technical description what went wrong in Intel QA process that made it possible to slip through this bricked NUC scenario into production?
Question to bjthinks: Any drawback(s) by disabling pm_async?
The docs I have found (which really doesnt say much on any drawback(s)) is:
Date: January 2009
Contact: Rafael J. Wysocki <email@example.com>
The /sys/power/pm_async file controls the switch allowing the
user space to enable or disable asynchronous suspend and resume
of devices. If enabled, this feature will cause some device
drivers' suspend and resume callbacks to be executed in parallel
with each other and with the main suspend thread. It is enabled
if this file contains "1", which is the default. It may be
disabled by writing "0" to this file, in which case all devices
will be suspended and resumed synchronously.
I'm running Fedora 23 Workstation on a NUC5i7RYH with 16 GB of DDR3L 2133 RAM and 512 GB of M.2 storage (NVMe). All BIOS settings are default, which I think includes both UEFI & Legacy boot. The BIOS version is current as of November 2015; I checked if an upgrade was needed and it wasn't. I'm sorry I'm unable to reboot the device at this moment to check the BIOS version number.
Take your time, as soon as possible send me the current BIOS version of the NUC. I noted you are using memories of 2133MHz; this device was intended to work with memories of DDR3L1333 and 1600MHz at 1.35v. Memories at higher speed are recognized but they can create an unstable system. Please perform a test using the memories at 1600MHz.
According to your last post, it is possible to get into the sleep mode but takes some time to wake from it. Is it correct?
1. The BIOS version is RYBDWi35.86A.0350.2015.0812.1722.
2. I'm aware that sales literature for the NUC5i7 specifies 1333 or 1600 speed DDR3L RAM. I ran memtest86+ after installing the 2133 speed RAM and waited for two full passes of the test (which takes several hours). There were 0 errors. Kindly note that memtest86+ can be found on the Fedora 23 Enterprise USB install image.
3. "According to your latest post, it is possible to get into the sleep mode but takes some time to wake from it. Is this correct?" No, that is not correct. Sleep or suspend mode (whatever you want to call it) has worked flawlessly since setting pm_async to 0.
If you're trying to replicate this issue, why don't you get an identically configured NUC, install Fedora 23 Workstation, put it on your desk, and use it for about a week? That would probably trigger the issue, since my NUC bricked itself when going to sleep on the second day I owned it.
That is unfortunately a common thing from level 1 support personel (no offence):
1) They dont answer your question.
2) If you ask multiple questions in the same case only one of the questions might be answered.
3) They try to point out something unrelevant to your case in order to not answer your question.
4) The case is then closed without actually resolving the issue you reported.
So you end up having to file 2-3 (or more) caseid's before the issue is handled correctly. The obvious reason for this is that the level 1 person will get a better statistics "ooh look at me, I solved 150 cases this week" where the true number is that it was just about 30 unique cases and not 150...
In your case to make mikec_intel happy, remove RAM from your NUC - what happens now?
If it still dead with no beeps or blinking leds in a specific order (to notify you that no RAM was detected) then its NOT a RAM related issue but rather a bad engineered NUC (given that you put it to sleep and now you cant make it to wake up no matter what).
The "bricked on sleep" is a know fault/error of NUC's and a computer should NEVER be bricked due to if the sleep mode occured async or sync. That is if it gets into some kind of lock you should then be able to remove external power, wait a few seconds and then boot the device as from a regular cold boot. Or as in the old days - long press on the power button to make the device to fully perform a cold reboot no matter of previous state.
The whole "remove bios battery and clear bios settings" is just as bad as it can get - specially when the moron who designed on placing the battery connector on the opposite side of the motherboard should be punished (if I need to remove the bios battery on my D54250WYK I need to completely disassemble the unit in order to get to the battery connector in order to disconnect it (and then reconnect it)). Here is a video of this in case you dont remember Intel NUC D54250WYK - Motherboard and cooler removal - YouTube
Intel NUC are really beautiful but at the same time it seems like Intel had some junior engineers involved in both design and architecture of these devices along with lacking quality assurance.
The good thing is that Intel is fixing these issues (for example you can order through support the new SATA daughterboard if you have that broken one or by BIOS update to (hopefully) fix the "bricked on sleep" even if it took about a year or so before this was resolved from Intels side) but it takes time for us the customers during which customers are being negatively affected by the bugs found.
1) Bad design of the SATA daughterboards which means that they must be replaced in order to fully function with SATA devices.
2) Something is broken with the external PSU (or the design of the power inlet in the NUC) making bass peaks and noise coming out of the speaker connector (heard during reboots and cold boots, will be bad to your ears if you had too large volume and the NUC connected to an amplifier and you didnt prepare for that bass peak to come).
3) "Bricked on sleep" - putting a NUC to sleep when using Linux will really put your NUC to sleep (its dead until you remove the BIOS battery and clear its BIOS settings).
That last case above might be fixed with v0038 BIOS update for the D54250WYK but it seems like other NUC models are affected too and the customers, for obvious reasons, are not too happy to verify this on their own if their current BIOS is fixed or not.
Hi bjthinks – thanks for your suggestion, which seems to be directly related to the suggestion made by prigaux, as detailed at post #10 in:
● 'NUC dead after suspend mode in Ubuntu 14.10', 23-Dec-2014 to 28-May-2015
...and involves using rc.local to write '0' into /sys/power/pm_async at each boot up.
I implemented prigaux's 'echo 0 > /sys/power/pm_async' suggested fix on my Intel NUC5i5RYH (rebadged as a System76 Meerkat), to try to eliminate its recurrent 'Ubuntu Suspend > Dead NUC' problem (under Ubuntu 15.04).
Sad to say it didn't work for me: I've experienced getting my NUC bricked by Ubuntu Suspend when /sys/power/pm_async contained '0', as well as when it contained '1'.
I've started my own thread detailing this recurrent 'Ubuntu Suspend > Dead NUC' problem:
• 'NUC5i5RYH Bricked by Ubuntu Suspend for Fifth Time'
We noted some compatible issues between our NUCs and some Linux flavors. It is hard to provide support with each distro. I would appreciate if you can reply with the kernel version, BIOS version and customized settings that you are using. If you are using a customized kernel, please send a copy of it (ISO); you can send it as a private message or use dropbox or any other method.
I am having the very same problem on a NUC5i5RYK, running Linux Mint (V. 17.3, Cinnamon 2.8), linux kernel: 184.108.40.206 generic, 16 gb RAM and 250 gb Samsung ssd. All BIOS settings at default.
I completely agree with all the other posters who have pointed out the very poor design that 1) allows the user to brick a computer from the keyboard by using a perfectly legitimate function (suspend), and 2) requires the user to disassemble a tiny delicate computer, with stiff wires attached to the WiFi chip with microscopic connectors that come off from the chip in the disassembly process. I would add that, given how many people have complained about this issue, the fact that there is still no access hole to allow us to reset the battery/bios from the outside with a long pin is nothing short of outrageous disregard to Intel's customers, who spent more money on the NUC than they would have if they had bought a small refurbished desktop PC to run their HTPC. My call to Intel "tech support" about this issue destroyed whatever respect I had for the company-- the technician at Intel knew much less about the NUC than I did, and learned whatever he knew in the process of talking to me.
Additional reasons why I should not have bought this box:
1) The mini-HDMI connector-- no one told me that I need an adapter to a regular HDMI, so I could not use the box until I got it.
2) The power button had the LED in it, so my finger hides the light, and there is no way to know if the machine is ON or OFF.
3) The stiff wires to the WiFi chip, held in place by the miniature snap connectors. It is hard to remove the motherboard without them coming off.
4) The "user guide" that came with it had almost no information (in several languages), and as a result I still don't know whether this NUC has an IR sensor. I bought a cheap Android TV box, and it came with a much more detailed description, plus a remote control.
In short-- I am advising all my friends and students to get something else. I wish someone had warned me!