- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello! I decided to ask this question directly at the source as I have failed all troubleshooting up to now.
I have recently bought an intel NUC NUC6CAYH and paired it with a single stick of "HyperX Impact, 4GB, DDR3, 1600MHz, CL9, 1.35v". I installed Fedora 27 on it. I was extremely pleased by it as a microserver and technically still am until I decided to add another "HyperX Impact, 4GB, DDR3, 1600MHz, CL9, 1.35v" and then the problems started. Every 3 to 5 hours the nuc would freeze, no kernel errors, no relevant logs, it simply... freezes and remains frozen until hard rebooted. Here is an example of a freeze in the logs:
Apr 22 03:17:17 plinky audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=sssd-secrets comm="systemd" exe="/usr/li
Apr 22 03:17:22 plinky systemd[1]: Started SSSD Kerberos Cache Manager.
Apr 22 03:17:22 plinky audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=sssd-kcm comm="systemd" exe="/usr/lib/s
Apr 22 03:17:22 plinky sssd[kcm][6634]: Starting up
Apr 22 03:17:22 plinky systemd[1]: Started SSSD Secrets Service responder.
Apr 22 03:17:22 plinky audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=sssd-secrets comm="systemd" exe="/usr/l
Apr 22 03:17:22 plinky sssd[secrets][6635]: Starting up
Apr 22 03:18:33 plinky wpa_supplicant[1073]: wlp2s0: WPA: Group rekeying completed with a0:ab:1b:89:96:5e [GTK=CCMP]
Apr 22 03:20:01 plinky anacron[6595]: Job `cron.daily' started
Apr 22 03:20:01 plinky run-parts[6641]: (/etc/cron.daily) starting logrotate
-- Reboot --
Apr 22 15:51:29 plinky kernel: Linux version 4.15.17-300.fc27.x86_64 (mailto:mockbuild@bkernel02.phx2.fedoraproject.org mockbuild@bkernel02.phx2.fedoraproject.org) (gcc version 7.3.1 20180303 (Red Hat 7.3.1-5) (GCC)) # 1 SM
Apr 22 15:51:29 plinky kernel: Command line: BOOT_IMAGE=/vmlinuz-4.15.17-300.fc27.x86_64 root=/dev/mapper/fedora_plinky-root ro rd.lvm.lv=fedora_plinky/root rd.lvm.lv=fedor
Apr 22 15:51:29 plinky kernel: x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
Apr 22 15:51:29 plinky kernel: x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
Apr 22 15:51:29 plinky kernel: x86/fpu: Supporting XSAVE feature 0x008: 'MPX bounds registers'
Apr 22 15:51:29 plinky kernel: x86/fpu: Supporting XSAVE feature 0x010: 'MPX CSR'
Apr 22 15:51:29 plinky kernel: x86/fpu: xstate_offset[3]: 576, xstate_sizes[3]: 64
Apr 22 15:51:29 plinky kernel: x86/fpu: xstate_offset[4]: 640, xstate_sizes[4]: 64
Apr 22 15:51:29 plinky kernel: x86/fpu: Enabled xstate features 0x1b, context size is 704 bytes, using 'compacted' format.
As you can see there is nothing except a gap between 3:20 and 15:51.
Troubleshooting I have attempted until now:
- Running 1 of the sticks in the lower slot, no issues
- Running 1 of the sticks in the higher slot, no issues
- Tested both sticks alone no issues
- 72 hours of memtest86+ with both sticks in, no issues and added more questions than answers as WHY THE F DID IT RUN 72 hours of memtest86+ but froze 3 hours after I booted into the operating system
I am simply out of Ideas... I currently have 2 of these NUC as I bought a second one for work and is also currently running 1 stick of the same ram. I will try putting the ram into the other nuc to see if the same problem repeats.
My current running theory is that this might be a voltage issue? the ram might be fine but are defective in the sense that they are running at higher voltage than spec or that the NUC is defective and not supplying enough voltage to the ram.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello, alex.barborica. Thank you very much for taking the time to reach the Intel Communities Team. I will do my best to assist you further.
I would highly appreciate if you can share with us the part number of your RAM. Furthermore, can you test this NUC with a Supported Operating System for your NUC and verify if this issue occurs? In this case, it will be only Windows® 10. Additionally, please test your RAM module on a different unit to double check if the issue occurs.
Antony S.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello! Thank you for the reply, yes I will test the ram with Windows 10 and in the other NUC which is already on windows 10. The part number of both the sticks is HX316LS9IB/4. I will report back next week with the results of the troubleshooting.
EDIT: As a last ditch effort I moved the NUC from the pretty hot location I was keeping it to a chillier location. Since then the problems have stopped. It would seem that having 2 sticks of ram was causing them to overheat. In the rack I was keeping it sandwiched between my NAS and router, ambient would have been somewhere near 40C. I didn't worry about it too much because I had the fan profile set to cool and I knew that NUCs can run pretty hot also, but apparently the RAM I bought is much more susceptible to heat.

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page