Originally I had a system with a single 3 TB drive for storage, just to try out unRAID.  System information:

M/B: ASUSTeK COMPUTER INC. - Q87M-E

CPU: Intel Core i5-4590 CPU @ 3.30GHz

HVM: Enabled

IOMMU: Disabled

Cache: 256 kB, 1024 kB, 6144 kB

Memory: 8 GB (max. installable capacity 32 GB)

    Kingston - 99U5584-003.A00LF - 672F9222 - 4096 MB @ 1600 MT/s

    Kingston - 99U5584-003.A00LF - 682F9822 - 4096 MB @ 1600 MT/s

Network: bond0: fault-tolerance (active-backup), mtu 1500

    eth0: 100 Mb/s, full duplex, mtu 1500

Kernel: Linux 4.18.20-unRAID x86_64

OpenSSL: 1.1.1a

 

Original, lone storage srive: WDC WD30EFRX-68N32N0

 

Did that for a few weeks and all was well, just the single parity-less cache-less unencrypted xfs volume.  Recently, installed a second 3 TB drive for storage, a brand new 4 TB drive for parity, a DVD R/W drive, and two sticks of RAM the system doesn't seem to see (still need to remove those).  First I added the second storage drive as an encrypted xfs volume.  Got that all setup, rebooted, and all was still looking good.

Then added the 4 TB drive as the parity drive, and left the parity build running overnight.  The next morning, the machine was completely unresponsive, with some kind of crash report showing on the monitor hooked up to the machine.  Hard shutdown the machine, rebooted, ran the parity check again and kept an eye on it from the "Main" page in the Web GUI for its 9 hour run, this time shutting down all Docker containers, and leaving all VMs stopped.  Shortly after it showed "completed" for the parity build status, Pushover on my phone showed "Parity disk returned to normal operation" and "Parity sync / Data rebuild finished (0 errors)".  Then, what looks like the same crash as the night before (see transcription below) and a completely unresponsive system again.

 

Transcription of the latter part of the information from the crash.  I saw it go by this time, and it looked like more information *may* have already scrolled off the screen in the first of two printings of text.

Hardware name: ASUS All Series/Q87M-E, BIOS 1501 03/10/2015
RIP: 0010:          (null)
Code:
RBP: 0000000000000001 R08: 0000000000000000 R09: 00000000ffffffff
Bad RIP value.
R10: ffff8801ec6e0961 R11: 0000000000000000 R12: 00000000fffffffe
RSP: 0018:ffffc90000f2bd90 EFLAGS: 00010202
R13: ffffc9000ed47c24 R14: 0000000000000000 R15: ffff8801e84b0d80
RAX: 0000000000000000 RBX: 00000000fffffffe RCX: 0000000000000000
RDX: 0000000000000001 RSI: 00000000fffffffe RDI: ffffc90000f2bdd4
FS:  00001476e874a700(0000) GS:ffff88021dd80000(0000) knlGS:0000000000000000
RBP: 0000000000000001 R08: 0000000000000000 R09: 00000000ffffffff
R10: ffff8801a9d46210 R11: 0000000000000000 R12: 00000000fffffffe
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
R13: ffffc90000f2bdd4 R14: 0000000000000000 R15: 0000000000000000
FS:  00001476e8549700(0000) GS:ffff88021dc80000(0000) knlGS:0000000000000000
CR2: ffffffffffffffd6 CR3: 00000002122e6004 CR4: 00000000001606e0
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffffffffffffd6 CR3: 00000002122e6004 CR4: 00000000001606e0
Call Trace:
 ? bsearch+0x37/0x5c
 ? map_id_up+0x86/0xad
 ? cp_new_stat+0xa7/0x17a
 ? hrtimer_cancel+0xc/0x16
 ? do_nanosleep+0xba/0x161
 ? __se_sys_newfstat+0x3c/0x5f
 ? do_syscall _64+0x57/0xe6
 ? entry_SYSCALL_64_after_hwframe+0x44/0xa9
Modules linked in: veth xt_CHECKSUM iptable_mangle ipt_REJECT ebtable_filter ebtables ip6table_filter ip6_tables- vhost_net tun v
host tap ipt_MASQUERADE iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 iptable_filter ip_tables nf_nat xfs dm_crypt al
gif_skcipher af_alg dm_mod dax nfsd lockd grace sunrpc md_mod bonding sr_mod cdrom x86_pkg_temp_thermal intel_powerclamp coretem
p kvm_intel kvm crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel pcbc aesni_intel aes_x86_64 crypto_simd cryptd gl
ue_helper intel_cstate intel_uncore intel_rapl_perf i2c_i801 i2c_core e1000e ahci video libahci wmi_bmof wmi backlight fan therm
al button pcc_cpufreq
CR2: 0000000000000000
---[ end trace 4084bf4d9df63b14 ]---
RIP: 0010:          (null)
Code: Bad RIP value.
RSP: 0018:ffffc9000ed47be0 EFLAGS: 00010002
RAX: 00000000fffffffe RBX: 00000000fffffffe RCX: 0000000000000000
RDX: 0000000000000001 RSI: 00000000fffffffe RDI: ffffc9000ed47c24
RBP: 0000000000000001 R08: 0000000000000000 R09: 00000000ffffffff
R10: ffff8801ec6e0961 R11: 0000000000000000 R12: 00000000fffffffe
R13: ffffc9000ed47c24 R14: 0000000000000000 R15: ffff8801e84b0d80
FS:  00001476e8549700(0000) GS:ffff88021dc80000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffffffffffffd6 CR3: 00000002122e6001 CR4: 00000000001606e0
_

 

While transcribing the above error message-- I took a photo to transcribe, rebooted, and changed array settings to remove the parity drive-- the following error popped up.  This time without making the system unresponsive.  Took a photo in case more information is needed, but this second one ends with the message "Fixing recursive fault but reboot is needed!"

 

Any ideas what might cause this?  Did I miss someone else already posting about this somewhere online?  Is there any other information which would be helpful?

 

Thanks in advance for any help.  Hoping I can use unRAID moving forward, since it's been so easy to set things up in the desired way so far.

Edited April 3, 20197 yr by yggdranil
Decided to type out the whole error display, instead of attaching a photo, to make it easier for anyone with a similar error to find it in a search.

Have you done a memtest?

 

See the Need Help? sticky for some more ideas about how to get us more information:

 

https://forums.unraid.net/topic/37579-need-help-read-me-first/

 

Any attempts to run Memtest86+ from the unRAID USB drive just rebooted the system.  Just now, made a separate Memtest86+ bootable USB and ran that three times: original system RAM layout, just the old sticks replaced with the new ones, and all four together.  All three configurations passed all tests, so I'm leaving it with the new four-stick (16GB) layout for now.  unRAID's Web GUI is now also showing all 16 GB of RAM, so I may've previously just had the two other sticks not completely seated.

 

Just now realized that it's possible to do the parity drive build/sync while the array is in maintenance mode, so I'll leave that going overnight to see if I come back to an unresponsive system or not.  Hopefully between fixing the RAM connection and building in maintenance mode, it'll all go well!

 

Extra: took a look in the BIOS settings and found VT-d, so that's enabled now.

 

Attached is the anonymized diagnostics archive from unRAID's Web GUI, just in case.

skatolo-diagnostics-20190402-2250.zip

Okay, all set!  The parity build (while in maintenance mode) finished.  I waited for all disks to come down to 0 B/s read/write, then waited a few minutes more.  No errors occurred, and the system didn't become unresponsive.  Then clicked "Done" to complete the parity build.  Stopped the array, brought it back up in not-maintenance mode, and it seems to all be working well.

 

Thanks for your quick response, Constructor!

1 hour ago, yggdranil said:

Thanks for your quick response, Constructor!

👍 "Newbie"!

Ah, "trurl".  Now I see where the username is, and where the forum activity rank is.