unRAID Server Release 6.2.0-beta23 Available


Recommended Posts

This isn't a V6.2 Beta issue.  This is likely that the NZBHydra container has been updated.  Scoot along over to the support thread and I'll check it out for you...

Its not 6.2, but the way that docker works, completely normal.  Image layers are shared between containers.  If its already there, being used by another app, then it won't redownload it.

 

No, it's because the container is auto-updating at startup...

Link to comment
  • Replies 229
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Posted Images

This isn't a V6.2 Beta issue.  This is likely that the NZBHydra container has been updated.  Scoot along over to the support thread and I'll check it out for you...

Its not 6.2, but the way that docker works, completely normal.  Image layers are shared between containers.  If its already there, being used by another app, then it won't redownload it.

 

No, it's because the container is auto-updating at startup...

 

Thanks for the feedback guys, I was able to get NZBHydra working with Sonarr with the help of the guys over at git-hub, workaround, but at least it works.  I did find it interesting that  I couldnt wipe the container, I suppose that is another question, and possibly not appropriate in this thread.

 

Thanks again.

Link to comment

This isn't a V6.2 Beta issue.  This is likely that the NZBHydra container has been updated.  Scoot along over to the support thread and I'll check it out for you...

Its not 6.2, but the way that docker works, completely normal.  Image layers are shared between containers.  If its already there, being used by another app, then it won't redownload it.

 

No, it's because the container is auto-updating at startup...

 

Thanks for the feedback guys, I was able to get NZBHydra working with Sonarr with the help of the guys over at git-hub, workaround, but at least it works.  I did find it interesting that  I couldnt wipe the container, I suppose that is another question, and possibly not appropriate in this thread.

 

Thanks again.

 

So if there is a bug, then you need to post instructions on how to recreate the problem and then problems get fixed.  Otherwise the only one who has benefit from this is yourself, which defeats the purpose of beta testing.

Link to comment

This isn't a V6.2 Beta issue.  This is likely that the NZBHydra container has been updated.  Scoot along over to the support thread and I'll check it out for you...

Its not 6.2, but the way that docker works, completely normal.  Image layers are shared between containers.  If its already there, being used by another app, then it won't redownload it.

 

No, it's because the container is auto-updating at startup...

 

Thanks for the feedback guys, I was able to get NZBHydra working with Sonarr with the help of the guys over at git-hub, workaround, but at least it works.  I did find it interesting that  I couldnt wipe the container, I suppose that is another question, and possibly not appropriate in this thread.

 

Thanks again.

 

So if there is a bug, then you need to post instructions on how to recreate the problem and then problems get fixed.  Otherwise the only one who has benefit from this is yourself, which defeats the purpose of beta testing.

 

Not sure why I would post an NZBHydra (Sonarr Integration) bug on an Unraid forum ?  Really not related to why I posted in the first place, I was wondering if it was possible to eradicate a container, leaving no traces behind, ie downloading from scratch.

 

If there are those interested in NZBHydra / Sonarr issue, you can look here.

 

https://github.com/theotherp/nzbhydra/issues/301?_pjax=%23js-repo-pjax-container

 

 

 

 

 

 

 

 

Link to comment

Not sure why I would post an NZBHydra (Sonarr Integration) bug on an Unraid forum ?  Really not related to why I posted in the first place, I was wondering if it was possible to eradicate a container, leaving no traces behind, ie downloading from scratch.

 

If there are those interested in NZBHydra / Sonarr issue, you can look here.

 

https://github.com/theotherp/nzbhydra/issues/301?_pjax=%23js-repo-pjax-container

 

It is possible to eradicate a container completely.  So if you can't there are only 2 options:

 

1.  There's a bug

2.  You're doing something wrong

Link to comment

Not sure why I would post an NZBHydra (Sonarr Integration) bug on an Unraid forum ?  Really not related to why I posted in the first place, I was wondering if it was possible to eradicate a container, leaving no traces behind, ie downloading from scratch.

 

If there are those interested in NZBHydra / Sonarr issue, you can look here.

 

https://github.com/theotherp/nzbhydra/issues/301?_pjax=%23js-repo-pjax-container

 

It is possible to eradicate a container completely.  So if you can't there are only 2 options:

 

1.  There's a bug

2.  You're doing something wrong

 

Thank You.

 

Link to comment

Not sure why I would post an NZBHydra (Sonarr Integration) bug on an Unraid forum ?  Really not related to why I posted in the first place, I was wondering if it was possible to eradicate a container, leaving no traces behind, ie downloading from scratch.

 

If there are those interested in NZBHydra / Sonarr issue, you can look here.

 

https://github.com/theotherp/nzbhydra/issues/301?_pjax=%23js-repo-pjax-container

 

It is possible to eradicate a container completely.  So if you can't there are only 2 options:

 

1.  There's a bug

2.  You're doing something wrong

 

Thank You.

You could always try to nuke your docker.img

Link to comment

Hey guys,

 

So update on the Docker updating error. I have since verified that all containers exhibit this strange behavior, and not just Plex. Whenever I click the blue 'Update Ready' button, it appears to be pulling Docker images from the web, extracting them... and then installing it. But then there's no step for deleting the orphaned (deprecated/old) image.

 

And then the icon turns red. See the screenshots for details. This only happens to CouchPotato and Plex; MineOS doesn't even display "Not Available" and just goes to Green until I press the check for updates button.

 

I have posted screenshots (with personal info removed) and diagnostics. Would anybody check, please? Thanks.

docker-error.png.bad1e3687a3c9657d5e59ab35154d4cd.png

derrickserver-diagnostics-20160704-1448.zip

Link to comment

Known bug (as was pointed out to me yesterday).  Kill the docker image and start again.

 

Thanks. Appdata is stored away from docker.img, so it should be safe, right?

 

And how should I nuke? Tell me if this is incorrect.

 

1. Stop Docker service thru Settings

2. SSH into server

3. Delete docker.img... where? Is it in /flash or something?

4. Restart Docker service thru Settings

5. Install Docker containers again.

 

EDIT: Just saw the option on Docker settings. No need for SSH or anythng. Thanks for the help!

Link to comment

Oh my god, it happened again.

 

The Docker update bug. Do I need to delete the image again?! This is so frustrating!

 

I mean, once is enough, right? When is this going to be fixed?

Link to comment

My guess is it'll be fixed in the next beta.  Which docker bug you talking about?

 

The one which perpetual 0 byte updates?  If so just ignore it, it's harmless.

 

Or the one with the manifest layer error? In which case, yeah, I think you need to recreate the docker.img

 

Or the http 400 error which has only affected two users, one more so that the other and seems localised to the Middle East (Israel to be specific)

 

Sent from my LG-H815 using Tapatalk

 

 

Link to comment

I thought this may have been solved, but just noticed it cropped up again in my syslog (certainly took longer to show up than previous beta (up 14 days now)).

Jul  4 12:47:20 Server kernel: CPU: 3 PID: 13786 Comm: qemu-system-x86 Tainted: G        W       4.4.13-unRAID #1
Jul  4 12:47:20 Server kernel: Hardware name: Gigabyte Technology Co., Ltd. To be filled by O.E.M./X99-SLI-CF, BIOS F21a 01/12/2016
Jul  4 12:47:20 Server kernel: 0000000000000000 ffff8807b7e937a8 ffffffff81369dde 0000000000000001
Jul  4 12:47:20 Server kernel: 0000000000000004 ffff8807b7e93840 ffffffff810bcc2f 0260c0c000000010
Jul  4 12:47:20 Server kernel: ffff880700000040 0000000400000040 0000000000000004 0000000000000004
Jul  4 12:47:20 Server kernel: Call Trace:
Jul  4 12:47:20 Server kernel: [<ffffffff81369dde>] dump_stack+0x61/0x7e
Jul  4 12:47:20 Server kernel: [<ffffffff810bcc2f>] warn_alloc_failed+0x10f/0x127
Jul  4 12:47:20 Server kernel: [<ffffffff810bfc46>] __alloc_pages_nodemask+0x870/0x8ca
Jul  4 12:47:20 Server kernel: [<ffffffff810bfe4a>] alloc_kmem_pages_node+0x4b/0xb3
Jul  4 12:47:20 Server kernel: [<ffffffff810f4434>] kmalloc_large_node+0x24/0x52
Jul  4 12:47:20 Server kernel: [<ffffffff810f6bd3>] __kmalloc_node+0x22/0x153
Jul  4 12:47:20 Server kernel: [<ffffffff810209af>] reserve_ds_buffers+0x18c/0x33d
Jul  4 12:47:20 Server kernel: [<ffffffff8101b3f0>] x86_reserve_hardware+0x135/0x147
Jul  4 12:47:20 Server kernel: [<ffffffff8101b452>] x86_pmu_event_init+0x50/0x1c9
Jul  4 12:47:20 Server kernel: [<ffffffff810ae064>] perf_try_init_event+0x41/0x72
Jul  4 12:47:20 Server kernel: [<ffffffff810ae4b5>] perf_event_alloc+0x420/0x66e
Jul  4 12:47:20 Server kernel: [<ffffffffa06435ab>] ? kvm_perf_overflow+0x35/0x35 [kvm]
Jul  4 12:47:20 Server kernel: [<ffffffff810b042b>] perf_event_create_kernel_counter+0x22/0x112
Jul  4 12:47:20 Server kernel: [<ffffffffa06436c1>] pmc_reprogram_counter+0xbf/0x104 [kvm]
Jul  4 12:47:20 Server kernel: [<ffffffffa064382f>] reprogram_gp_counter+0x129/0x146 [kvm]
Jul  4 12:47:20 Server kernel: [<ffffffffa0783b1e>] intel_pmu_set_msr+0x2bd/0x2ca [kvm_intel]
Jul  4 12:47:20 Server kernel: [<ffffffffa0643b14>] kvm_pmu_set_msr+0x15/0x17 [kvm]
Jul  4 12:47:20 Server kernel: [<ffffffffa0625a55>] kvm_set_msr_common+0x921/0x983 [kvm]
Jul  4 12:47:20 Server kernel: [<ffffffffa06269fe>] ? kvm_arch_vcpu_load+0x133/0x173 [kvm]
Jul  4 12:47:20 Server kernel: [<ffffffffa07833ba>] vmx_set_msr+0x2ec/0x2fe [kvm_intel]
Jul  4 12:47:20 Server kernel: [<ffffffffa0622422>] kvm_set_msr+0x61/0x63 [kvm]
Jul  4 12:47:20 Server kernel: [<ffffffffa077c9ba>] handle_wrmsr+0x3b/0x62 [kvm_intel]
Jul  4 12:47:20 Server kernel: [<ffffffffa07815f9>] vmx_handle_exit+0xfbb/0x1053 [kvm_intel]
Jul  4 12:47:20 Server kernel: [<ffffffffa07830bf>] ? vmx_vcpu_run+0x30e/0x31d [kvm_intel]
Jul  4 12:47:20 Server kernel: [<ffffffffa062bf76>] kvm_arch_vcpu_ioctl_run+0x38a/0x1080 [kvm]
Jul  4 12:47:20 Server kernel: [<ffffffffa06269fe>] ? kvm_arch_vcpu_load+0x133/0x173 [kvm]
Jul  4 12:47:20 Server kernel: [<ffffffffa061e0ec>] kvm_vcpu_ioctl+0x178/0x499 [kvm]
Jul  4 12:47:20 Server kernel: [<ffffffff8149fb20>] ? vfio_pci_write+0x14/0x19
Jul  4 12:47:20 Server kernel: [<ffffffff8149b731>] ? vfio_device_fops_write+0x1f/0x29
Jul  4 12:47:20 Server kernel: [<ffffffff81109970>] ? __vfs_write+0x21/0xb9
Jul  4 12:47:20 Server kernel: [<ffffffff81117b95>] do_vfs_ioctl+0x3a3/0x416
Jul  4 12:47:20 Server kernel: [<ffffffff8111fb96>] ? __fget+0x72/0x7e
Jul  4 12:47:20 Server kernel: [<ffffffff81117c46>] SyS_ioctl+0x3e/0x5c
Jul  4 12:47:20 Server kernel: [<ffffffff81622c6e>] entry_SYSCALL_64_fastpath+0x12/0x6d
Jul  4 12:47:20 Server kernel: Mem-Info:
Jul  4 12:47:20 Server kernel: active_anon:1901826 inactive_anon:8722 isolated_anon:0
Jul  4 12:47:20 Server kernel: active_file:554832 inactive_file:653060 isolated_file:0
Jul  4 12:47:20 Server kernel: unevictable:4604002 dirty:1076 writeback:0 unstable:0
Jul  4 12:47:20 Server kernel: slab_reclaimable:273973 slab_unreclaimable:32003
Jul  4 12:47:20 Server kernel: mapped:31631 shmem:137158 pagetables:16790 bounce:0
Jul  4 12:47:20 Server kernel: free:89632 free_pcp:59 free_cma:0
Jul  4 12:47:20 Server kernel: Node 0 DMA free:15896kB min:64kB low:80kB high:96kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15980kB managed:15896kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes
Jul  4 12:47:20 Server kernel: lowmem_reserve[]: 0 667 31899 31899
Jul  4 12:47:20 Server kernel: Node 0 DMA32 free:127336kB min:2824kB low:3528kB high:4236kB active_anon:298168kB inactive_anon:1092kB active_file:968kB inactive_file:736kB unevictable:367324kB isolated(anon):0kB isolated(file):0kB present:831172kB managed:821456kB mlocked:367324kB dirty:0kB writeback:0kB mapped:1508kB shmem:8440kB slab_reclaimable:16520kB slab_unreclaimable:1760kB kernel_stack:448kB pagetables:2484kB unstable:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
Jul  4 12:47:20 Server kernel: lowmem_reserve[]: 0 0 31231 31231
Jul  4 12:47:20 Server kernel: Node 0 Normal free:215296kB min:132272kB low:165340kB high:198408kB active_anon:7309136kB inactive_anon:33796kB active_file:2218360kB inactive_file:2611504kB unevictable:18048684kB isolated(anon):0kB isolated(file):0kB present:32505856kB managed:31981696kB mlocked:18048684kB dirty:4304kB writeback:0kB mapped:125016kB shmem:540192kB slab_reclaimable:1079372kB slab_unreclaimable:126252kB kernel_stack:12848kB pagetables:64676kB unstable:0kB bounce:0kB free_pcp:236kB local_pcp:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
Jul  4 12:47:20 Server kernel: lowmem_reserve[]: 0 0 0 0
Jul  4 12:47:20 Server kernel: Node 0 DMA: 0*4kB 1*8kB (U) 1*16kB (U) 0*32kB 2*64kB (U) 1*128kB (U) 1*256kB (U) 0*512kB 1*1024kB (U) 1*2048kB (U) 3*4096kB (M) = 15896kB
Jul  4 12:47:20 Server kernel: Node 0 DMA32: 264*4kB (UME) 287*8kB (UME) 329*16kB (UME) 264*32kB (UME) 247*64kB (UME) 152*128kB (UME) 99*256kB (UME) 49*512kB (UME) 22*1024kB (ME) 1*2048kB (E) 0*4096kB = 127336kB
Jul  4 12:47:20 Server kernel: Node 0 Normal: 35820*4kB (UME) 8899*8kB (UME) 128*16kB (UME) 14*32kB (UM) 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 216968kB
Jul  4 12:47:20 Server kernel: 1344904 total pagecache pages
Jul  4 12:47:20 Server kernel: 0 pages in swap cache
Jul  4 12:47:20 Server kernel: Swap cache stats: add 0, delete 0, find 0/0
Jul  4 12:47:20 Server kernel: Free swap  = 0kB
Jul  4 12:47:20 Server kernel: Total swap = 0kB
Jul  4 12:47:20 Server kernel: 8338252 pages RAM
Jul  4 12:47:20 Server kernel: 0 pages HighMem/MovableOnly
Jul  4 12:47:20 Server kernel: 133490 pages reserved
Jul  4 12:47:20 Server kernel: qemu-system-x86: page allocation failure: order:4, mode:0x260c0c0

 

This repeats multiple times with a couple of CPU assignments listed with the same error.

I assume this is an OOM condition, possibly from fragmentation or QEMU overhead.

I don't believe I'm assigning more than reasonable to the VM's, and leaving the host without enough for operations/Docker.

 

 

I also had this show up once, which was never there previously. The device is a PCIe root port, so not specifically an end device however has not occured again.

Jun 23 14:58:45 Server kernel: pcieport 0000:00:01.0: AER: Corrected error received: id=0008
Jun 23 14:58:45 Server kernel: pcieport 0000:00:01.0: PCIe Bus Error: severity=Corrected, type=Data Link Layer, id=0008(Transmitter ID)
Jun 23 14:58:45 Server kernel: pcieport 0000:00:01.0:   device [8086:2f02] error status/mask=00001000/00002000
Jun 23 14:58:45 Server kernel: pcieport 0000:00:01.0:    [12] Replay Timer Timeout  

 

Diagnostics attached.

server-diagnostics-20160705-0734.zip

Link to comment

I thought this may have been solved, but just noticed it cropped up again in my syslog (certainly took longer to show up than previous beta (up 14 days now)).

I'm not positive I understand your statement, as it almost sounds like you've had this before?  It's the first one like this that I've seen.

 

It's not an OOM, they are clearly marked as such and result in the kernel selecting and killing a process with lots of memory allocated, to free it up and let the rest of the system continue.  That didn't happen here.  In fact, this begins by announcing a 'Warning' (I've never seen that happen before!), then reports that RAM pages could not be allocated, but then carries on like everything's normal.  Memory numbers look fine to me, but I'm not an expert.  Only one *feels* wrong, "0 pages HighMem/MovableOnly", but I don't know if it is truly a bad thing.  There appears to be plenty of reclaimable memory.

 

The system does report 'Tainted', so it should be considered unreliable and rebooted.

 

As it's an unusual occurrence, I've nothing else to comment, except try the usual steps - check for a newer BIOS, and firmware if applicable, and wait for a newer kernel.

 

Edit: forgot to mention one more symptom, there are 3 'migration' processes running at CPU of '99', which would appear to be another indicator that the system is ailing, but I don't know more.  There are 12 migration processes, one per core to help distribute the CPU workload.  The fact that 3 are running near max means something's wrong.

Link to comment

This just cropped up for me as well after about 12 days of uptime. Diags attached.

I have to be careful what I say, as it appears to me you have more Linux experience than I do!  ;)

 

Yours is a different problem than his, an unhandled interrupt (IRQ 16), and I believe you'll see a similar case a few pages back.  What's different though is that commonly the interrupt handler is almost always a USB driver, and then maybe another handler, such as one from the mvsas module.  Your only handler attached to IRQ 16 appears to be 'vfio_intx_handler', the first time I've seen it implicated.  It looks to me to be a critical part of the low level communications between VM's and the hosting services.  I think all you can do is wait for a newer kernel with updated KVM subsystems.  You do need to reboot, to restore IRQ 16 servicing.

Link to comment

I thought this may have been solved, but just noticed it cropped up again in my syslog (certainly took longer to show up than previous beta (up 14 days now)).

I'm not positive I understand your statement, as it almost sounds like you've had this before?  It's the first one like this that I've seen.

 

These messagess have been common for me on the last couple of beta's, and I have reported as such in at least one other of the threads.

I honestly don't know what causes it, just know that over time I get these messages again, and again, and again.

They do not result in instability (which to me is quite surprising) and my assumptions is whatever is managing memory reallocates this, and everything goes back to working as it should (meaning no more of these in the syslog). On previous beta's I received these messages much earlier in regards to uptime.

These parts of that snippet don't seem correct, as I'd assume these should be a value > "0" 

Jul  4 12:47:20 Server kernel: 0 pages in swap cache
Jul  4 12:47:20 Server kernel: Swap cache stats: add 0, delete 0, find 0/0
Jul  4 12:47:20 Server kernel: Free swap  = 0kB
Jul  4 12:47:20 Server kernel: Total swap = 0kB
Jul  4 12:47:20 Server kernel: 8338252 pages RAM
Jul  4 12:47:20 Server kernel: 0 pages HighMem/MovableOnly

 

When I first started getting these I assumed it was my setup, as I recently had my motherboard die, and this board (exact same as prior) is pickier about ram timings (I have them set to relaxed timings, no XMP, a bit more voltage just in case).

Anyhow, I've ran Memtest for plenty of passes with 0 errors (can only run the included Memtest in default/non multithreaded mode or it will fail), however I've considered grabbing a newer version that is aware of DDR4 and the X99 chipset, and running that for stability tests.

 

I do have a BIOS update available, and will venture on installing it soon. There is a good reason I have delayed this, as I have tested with newer versions (there were plenty of beta release bios's for my board, I am actually currently on one), however they had worse issues such as: not being able to get into setup, a warning about PCIe resources low, etc...

Most of the bios updates are because of the newer CPU's available for the X99 socket, now that Skylake versions have been released.

 

I mentioned this same issue in the B21 thread here http://lime-technology.com/forum/index.php?topic=48193.msg471875#msg471875

Similar issue, supposedly fixed and should be included in the current kernel https://bugzilla.kernel.org/show_bug.cgi?id=93251

Fixed in v4.0

commit 744961341d472db6272ed9b42319a90f5a2aa7c4

    kvm: avoid page allocation failure in kvm_set_memory_region()

 

Thanks for looking, I appreciate any help with this!

 

Edit:

Edit: forgot to mention one more symptom, there are 3 'migration' processes running at CPU of '99', which would appear to be another indicator that the system is ailing, but I don't know more.  There are 12 migration processes, one per core to help distribute the CPU workload.  The fact that 3 are running near max means something's wrong.

I will look into this further, as I have no experience with something of that nature.

Link to comment

6.2 rc1 in some days :D

 

Is there a plan to update this docker, or is it no longer supported?

 

limetech's Plex docker app was updated to version 1.0.0.2261 on June 29th...

 

Thanks eschultz.  Sorry for the stupid question, I'm still kind of getting the hang of dockers, but what's the preferred method of updating plex?  The docker app was not showing any updates, and a manual restart/shut down/start up of the docker was not working either.  I did finally get it to work by using the force update recommended above.  Is that the best way to do it from here on out?

 

The next release of unRAID 6.2, rc1, will properly show when a docker update is actually available so you won't have to do a 'force update' any longer after that... or until Docker changes the Docker Hub API schema again (which is what broke these status updates for some of the latest docker containers this time)

 

rc1 has been 'done' for a few days now but we've just been nitpicking last minute minor details and prepping for public release.  BRiT: soontm means very soon, at least this time.  ;D

 

https://lime-technology.com/forum/index.php?topic=40654.msg481848#msg481848

 

 

 

Any news on fixing this bug btw?

https://lime-technology.com/forum/index.php?topic=40826.msg458827#msg458827

Link to comment

I thought this may have been solved, but just noticed it cropped up again in my syslog (certainly took longer to show up than previous beta (up 14 days now)).

I'm not positive I understand your statement, as it almost sounds like you've had this before?  It's the first one like this that I've seen.

 

These messagess have been common for me on the last couple of beta's, and I have reported as such in at least one other of the threads.

I honestly don't know what causes it, just know that over time I get these messages again, and again, and again.

They do not result in instability (which to me is quite surprising) and my assumptions is whatever is managing memory reallocates this, and everything goes back to working as it should (meaning no more of these in the syslog). On previous beta's I received these messages much earlier in regards to uptime.

I found your link, to beta21, and yes it appears very similar, I must have missed it.  Don't have anything to add.  The fix that helped others was apparently not complete enough to help you, but perhaps in the future ...

 

These parts of that snippet don't seem correct, as I'd assume these should be a value > "0" 

Jul  4 12:47:20 Server kernel: 0 pages in swap cache
Jul  4 12:47:20 Server kernel: Swap cache stats: add 0, delete 0, find 0/0
Jul  4 12:47:20 Server kernel: Free swap  = 0kB
Jul  4 12:47:20 Server kernel: Total swap = 0kB

You aren't using a swap file, so they are zero.  If you are interested, you might try the Swap plugin, and add some swap space, see if it makes any difference.  A lack of a swap file is probably one difference between others (non unRAID users) and you.

 

When I first started getting these I assumed it was my setup, as I recently had my motherboard die, and this board (exact same as prior) is pickier about ram timings (I have them set to relaxed timings, no XMP, a bit more voltage just in case).

This does not look like a hardware issue, more like a bug in the low level memory management somewhere.

 

Anyhow, I've ran Memtest for plenty of passes with 0 errors (can only run the included Memtest in default/non multithreaded mode or it will fail), however I've considered grabbing a newer version that is aware of DDR4 and the X99 chipset, and running that for stability tests.

Try the PassMark Memtest86, it has been updated for the newer memory chips and their newer technologies.

 

I do have a BIOS update available, and will venture on installing it soon. There is a good reason I have delayed this, as I have tested with newer versions (there were plenty of beta release bios's for my board, I am actually currently on one), however they had worse issues such as: not being able to get into setup, a warning about PCIe resources low, etc...

Most of the bios updates are because of the newer CPU's available for the X99 socket, now that Skylake versions have been released.

 

I mentioned this same issue in the B21 thread here http://lime-technology.com/forum/index.php?topic=48193.msg471875#msg471875

Similar issue, supposedly fixed and should be included in the current kernel https://bugzilla.kernel.org/show_bug.cgi?id=93251

Fixed in v4.0

commit 744961341d472db6272ed9b42319a90f5a2aa7c4

    kvm: avoid page allocation failure in kvm_set_memory_region()

 

Edit:

Edit: forgot to mention one more symptom, there are 3 'migration' processes running at CPU of '99', which would appear to be another indicator that the system is ailing, but I don't know more.  There are 12 migration processes, one per core to help distribute the CPU workload.  The fact that 3 are running near max means something's wrong.

I will look into this further, as I have no experience with something of that nature.

I don't either.  I noticed it occurs in your beta21 failures also, the same 3 99's.  You might check the ps report before the page allocation errors occur, and determine if this is normal or not, for your system.  I would be interested in knowing what is associated with them, when do they rise so high.

Link to comment

Oh my god, it happened again.

 

The Docker update bug. Do I need to delete the image again?! This is so frustrating!

 

I mean, once is enough, right? When is this going to be fixed?

 

Yeah.. still happening for me. Annoyance factor is high, but really not a game stopping bug.  Gotta love betas ;)

Link to comment

Hopefully rc1 will resolve a lot of these issues, I heard it was "imminent" but that was 24 hours ago so yeh....  soon™

@archedraft  It's time.... you grab the pitchforks, I'll grab the torches... lol

 

Sent from my LG-H815 using Tapatalk

 

Link to comment
Guest
This topic is now closed to further replies.