NUC failure after Linux sleep / hibernate / suspend: SOLUTION(?)

[BJohn28]

There have been many posts about NUCs failing to wake up and/or getting completely bricked after the Linux kernel puts the device to sleep. It would seem there is an incompatibility between how the Linux kernel puts the NUC to sleep, and the NUC's hardware or BIOS. I don't have a clue whose fault this is, but it SEEMS LIKE* a successful workaround is to force the Linux kernel to use synchronous power management, meaning the NUC's hardware devices will be shut down one by one, rather than all at once in parallel (which is the default).

* I have not reproduced the problem after implementing this solution, but that doesn't mean it's solved -- it could just be a rare issue, or I might just have been lucky since following these steps. Please reply with your experiences so we know if this info is correct.

If your NUC is bricked and will not power on, you can probably recover it by disconnecting the CMOS battery for a short time. Briefly: Disconnect power. Flip over. Remove four foot screws. Ground yourself. Expose sensitive underbelly. Remove M.2 drive if needed (it may block access to one of the motherboard screws). Remove two black screws holding motherboard down. Gently lift motherboard out, being careful not to scratch its components or circuit traces against anything hard or metal. Unplug CMOS battery for a minute, then plug back in. Reverse steps. NUC should now turn on when power button is pressed.

TO PREVENT THIS PROBLEM FROM HAPPENING IN THE FUTURE:

sudo bash

cat << EOF > /etc/systemd/system/disable-async-power-management.service

[Unit]

Description=Disable asynchronous power management

DefaultDependencies=no

OnFailure=emergency.target

[Service]

Type=oneshot

ExecStart=/bin/sh -c "echo 0 > /sys/power/pm_async"

RemainAfterExit=yes

[Install]

RequiredBy=sysinit.target

EOF

systemctl start disable-async-power-management.service

# The next command should print 0 and not 1

cat /sys/power/pm_async

systemctl enable disable-async-power-management.service

[Anonymous]

Hi bjthinks,

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.

http://www.intel.com/support/motherboards/desktop/sb/CS-034034.htm Intel® NUC — Supported Operating Systems

Regards,

MiKe C

[AApac]

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:

https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-power https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-power

What: /sys/power/pm_async

Date: January 2009

Contact: Rafael J. Wysocki <</span>mailto:rjw@rjwysocki.net rjw@rjwysocki.net>

Description:

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.

[BJohn28]

The pm_async setting doesn't seem to make any difference e.g. in how fast the NUC goes to sleep or wakes up, at least not that I've noticed.

[Anonymous]

Hi bjthinks,

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?

Regards,

Mike C

[BJohn28]

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.

[Anonymous]

Hi bjthinks,

Please make a test using the RAM at Intel's recommended settings. Let me know how many GBs you are using. I will make a test from my side.

Regards,

Mike C

[BJohn28]

I have no idea what you want me to "test". The NUC works flawlessly with pm_async set to 0, and bricks itself when going to sleep with pm_async set to the default. I'm providing this information to other NUC owners and Intel engineers who can make use of it. It does not appear that you can.

[AApac]

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 https://www.youtube.com/watch?v=2EPZQUaJozk 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.

Currently:

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.

[BJohn28]

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.

[TJone12]

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" /message/309188# 309188 https://communities.intel.com/message/309188# 309188 ...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'

" /thread/96168 https://communities.intel.com/thread/96168

[Anonymous]

Hi All,

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.

Regards,

Mike C

[GGabr]

I am having the very same problem on a NUC5i5RYK, running Linux Mint (V. 17.3, Cinnamon 2.8), linux kernel: 3.19.0.32 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!

[Anonymous]

Hi venik212,

I am going to make a test with the Intel® NUC Kit 5i5RYK and Linux Mint. I would post my findings as soon as possible.

Regards,

Mike C

[GGabr]

Any news from the testing grounds of the NUC regarding the "dead-after-suspend" defect?

[Cesar_B_Intel]

Hello venik212

We have just released latest BIOS Version: 0353 (Latest) https://downloadcenter.intel.com/download/25675/BIOS-Update-RYBDWi35-86A- Download BIOS Update [RYBDWi35.86A]

Please upgrade to latest version and let us know if issue is resolved.

Regards,

Caesar B_Intel.

[GGabr]

I had installed V353, and so far (several days) my nuc5i5RYK wakes up just fine when I use the wireless keyboard to wake it up.

I shall report here any new failures.

I am using Linux Mint 17.3/Cinnamon 2.8.6.

[GGabr]

I am reposting this here, in the hope that someone from Intel will pay attention and help.

Ding Dong, the NUC is dead (well... perhaps useless or unusable is more accurate now).

After using the NUC for several weeks, always being careful to never touch the treacherous power button-- today I was unable to wake it from its suspension. However, previously it was just dead, and disconnecting the battery (stupidly hidden underneath the motherboard, requiring disassembly) would revive it, this time the blue light on the power button indicated some activity, and occasionally the orange disk icon would shine, too. But the TV to which the NUC is connected via the HDMI connector reported no signal. I disassembled it, disconnected the battery, and put it all back together, but the symptoms remained unchanged. Long or short presses of the power button, with or without an audio cable plugged into the front, did not resolve the issue.

In despair, I plugged a USB flash drive with Linux MINT (the same one that was running on the SSD inside the NUC), but the NUC refused to boot from it, although another computer did.

Consequently I am clueless as to how to proceed. All the tricks that worked in the past failed this time (unplugging the WiFi receiver and plugging it back in, using a wired keyboard, disconnecting teh power for 30 minutes, etc.).

I now hate this thing-- it was great when it worked, but to have an unusable computer after only about 2-3 months of use is pathetic. In several decades of using computers of all sizes, operating systems and makes, this has been the most fragile and frustrating experience. I now consider the moniker "Intel Inside" as a warning, similar to the Surgeon General warning on the hazards of cigarettes.

Any useful advice/information would be greatly appreciated.

PS: I have the latest BIOS (V. 353), Linux/Mint 17.3/Cinnamon 2.8.5, NUC5i5RYK. The BIOS settings are as recommended in previous settings to avoid confusing the USB system.

[Anonymous]

Hi venik212,

In regards to your issue with the operating system Linux Mint. I suggest you to get into the BIOS and reset settings with F9 then, save changes. Try again to get into your operating system.

Regards,

Mike C

[GGabr]

Thanks for responding. My problem is that I CANNOT GET TO THE BIOS or to the operating system. When I press the power button, the blue light goes on, but the TV screen still says: no connection. As I mentioned above, I also tried to reboot from a USB drive, but that failed too.

I already took the NUC apart and disconnected the CMOS battery, but that did not help. I tried to install the latest BIOS (V.354), but I did not see the prompt on the screen to click F7. I am really stuck, and would appreciate any help. I loved the NUC when it worked, but it has been VERY frustrating.

[GGabr]

Reading posts on a Linux forum I learned that Intel has issued a new version of the BIOS, V. 354. I finally managed to install it, and now my NUC is alive again.

Perhaps V. 354 will be the charm that will end this unpleasant experience.