Hi all — I’m looking for help diagnosing a parity check crash/stall on an existing Unraid 7.1.4 install. Diagnostic file attached.

My issues started after I configured the parity tuning plugin to perform a check on 6/3. I was under the impression it would pause when mover ran several hours later, then would pick up again later. I ended up with what appeared to be a mover constantly crashing/stalling, immich was stuck, and the nightly email notice I get was giving weird numbers saying it completed the parity check in only a few minutes. I could not stop the array and had to do a hard reset. I seem to be stable now.

My questions are:

Should I be safe to begin a parity check again?

How do I set the tuning so I can schedule a parity check to run automatically once a month and not worry about the mover getting in the way?

Thanks for your help. Full disclosure, below is a summary from my ChatGPT once it finally got stable again.

Quick recap: this is an existing Unraid 7.1.4 install with dual parity. The array is currently started, mounted, and usable, with sbSyncErrs=0 and no active parity check progress. The problem began after I configured scheduled/partial parity checks using the Parity Check Tuning plugin. A correcting dual-parity check started and repeatedly crashed/stalled immediately at mdResyncPos=0, with the syslog showing Oops: general protection fault in raid6_avx21_gen_syndrome, followed by check_parity and unraidd0 exited.

I removed the Parity Check Tuning plugin, disabled scheduled parity checks, confirmed that no active cron parity checks remain, and the array is now stable. However, I have not attempted another parity check because I do not want to re-trigger the crash. I’m looking for guidance on whether these points point to an Unraid/kernel RAID6 issue, hardware/CPU/RAM issue, or leftover parity state, and what the safest next step is.

System / context

• Unraid version: 7.1.4

• Kernel shown in logs: 6.12.24-Unraid

• Dual parity array: parity + parity 2

• Largest disk / parity size: 12 TB

• Array currently starts and is usable

• Current status shows no active parity check and no sync errors:

sbSyncErrs=0
mdState=STARTED
mdResyncAction=check P Q
mdResyncSize=11718885324
mdResyncCorr=0
mdResync=0
mdResyncPos=0
mdResyncDt=0
mdResyncDb=0

The mdResyncAction=check P Q label appears stale because mdResync=0, mdResyncPos=0, mdResyncDt=0, and mdResyncDb=0.

What happened

This started after I configured scheduled/partial parity checks using the Parity Check Tuning plugin. During/after that process, a correcting dual-parity check started and immediately crashed/stalled.

The first failure showed the parity check starting and then crashing in the RAID6 parity code:

mdcmd: check correct
md: recovery thread: check P Q ...
Oops: general protection fault
RIP: raid6_avx21_gen_syndrome
check_parity+0x204/0x360 [md_mod]
unraidd+0xedf/0x1280 [md_mod]
note: unraidd0 exited

After that, Unraid showed the check stuck at zero progress:

mdResyncAction=check P Q
mdResyncCorr=1
mdResyncPos=0
mdResyncDt=...
mdResyncDb=0

The array could not be stopped cleanly from the GUI; Stop was greyed out or the array stayed stuck stopping. A normal reboot did not complete, and I had to reboot using SysRq/physical reboot.

Troubleshooting performed

• Captured diagnostics and syslogs before rebooting.

• Removed the Parity Check Tuning plugin.

• Booted into Safe Mode with GUI.

• Even in Safe Mode, the parity check state came back as correcting/stuck:

mdResyncCorr=1
mdResyncPos=0

• Rebooted again.

• Now in normal mode, the array starts and is stable. Current status is:

sbSyncErrs=0
mdState=STARTED
mdResyncAction=check P Q
mdResyncSize=11718885324
mdResyncCorr=0
mdResync=0
mdResyncPos=0
mdResyncDt=0
mdResyncDb=0

• Parity Check Tuning appears removed:

ls -lah /boot/config/plugins | grep -i parity

returned nothing.

• Built-in scheduled parity check cron was removed after disabling scheduled parity checks:

cat /boot/config/plugins/dynamix/parity-check.cron
cat: /boot/config/plugins/dynamix/parity-check.cron: No such file or directory

• Active crontab does not show any parity/mdcmd check job:

crontab -l | grep -iE "mdcmd|parity|NOCORRECT|check"

returned nothing.

• dynamix.cfg currently shows:

[parity]
write="NOCORRECT"

Current state

The array is currently usable and mounted:

/mnt/user mounted
/mnt/disk1 mounted
/mnt/cache mounted

I am avoiding any manual parity check for now because the prior attempts repeatedly crashed at:

raid6_avx21_gen_syndrome
check_parity
unraidd0 exited

Question

What is the recommended next step?

Specifically:

1. Is this likely an Unraid/kernel RAID6 parity calculation issue, a plugin-triggered issue, or a hardware/CPU/RAM issue?

2. Is there a safe way to clear the stale mdResyncAction=check P Q label/state while mdResync=0?

3. Should I try a non-correcting parity check again, or avoid parity checks until further guidance?

4. Are there specific BIOS settings, CPU features, RAM tests, or Unraid settings I should check given the crash is in raid6_avx21_gen_syndrome?

5. Since this was the original install, I do not have a prior Unraid version available to roll back to. Is there a recommended version to install/upgrade/downgrade to for this issue?

Diagnostics zip attached.

fileserver-diagnostics-20260610-2036.zip

There's no parity check on those diags, start a new one and post new diags if it crashes.

Regarding the Parity Tuning plugin - it does not start checks only pauses/resumes them after they have started according to the settings you use. The initiation of checks is controlled by what you have set at the standard Unraid level under Settings->Scheduler. You can turn off the option in the plugin to run checks in increments if you want but still retain some of the other features. If you want the plugin to pause a check while mover runs then make sure you have configured the plugin for this.

Regardless nothing you have posted explains why you should get the problems you describe. Things like a check running at the same time as mover should still work fine - just degrade each others performance significantly. Hopefully getting diagnostics after a crash might prove useful. The 'oops' you mention is not normal - that does look like it could be hardware related but more information is needed.

4 hours ago, JorgeB said:

There's no parity check on those diags, start a new one and post new diags if it crashes.

Thank you. I'll interpret this as answering the question "Should I be safe to begin parity checks again?". Thank you for the response. I'll work on this again after work and report back

3 hours ago, itimpi said:

Regarding the Parity Tuning plugin - it does not start checks only pauses/resumes them after they have started according to the settings you use. The initiation of checks is controlled by what you have set at the standard Unraid level under Settings->Scheduler. You can turn off the option in the plugin to run checks in increments if you want but still retain some of the other features. If you want the plugin to pause a check while mover runs then make sure you have configured the plugin for this.

Regardless nothing you have posted explains why you should get the problems you describe. Things like a check running at the same time as mover should still work fine - just degrade each others performance significantly. Hopefully getting diagnostics after a crash might prove useful. The 'oops' you mention is not normal - that does look like it could be hardware related but more information is needed.

Thank you. I'll run a parity check again, and then, assuming it does not crash this time, I'll reinstall the tuning plugin and try again.

I started a fresh parity check again, and it has stalled again. Disgnotstics attached.

fileserver-diagnostics-20260613-2119.zip

The syslog shows you getting General Protection Faults happening as soon as you start the Parity Check. Have you run a memtest recently in case you have a RAM issue?

Not sure what else to suggest at the moment. Not sure if your CPU is one that can be affected by the Intel 13th/14th generation issue?

You might want to also disable mover logging unless you are investigating a Mover issue as it keeps the logs simpler.

Unraid driver is crashing; this is almost always a hardware issue, and considering you are using a 14600K, it's by far the #1 suspect.

@itimpi and @JorgeB , thank you for your feedback.

Quick update:

• I rebooted and captured fresh diagnostics with the array currently not started/offline. I’ve attached the new diagnostics ZIP.

• I also ran two full cycles of Memtest86+ v6.2 with no errors, and confirmed the motherboard BIOS is on the latest version available for my board that addresses the Intel 13th/14th gen microcode issue.

For context, after applying that BIOS/microcode update in June of 2025, I have since completed two parity checks over the last year without issue. This current failure seems new.

The prior diagnostics appeared to show the crash immediately after starting parity check, with the general protection fault in:

raid6_avx21_gen_syndrome -> check_parity -> unraidd

Given the clean memtest, current BIOS, and the fact that the last two parity checks completed successfully, is there a way to better confirm whether this is actually the 14600K / Intel CPU issue versus another hardware or Unraid/kernel issue?

For now, I’m sitting rebooted with the array offline and have not started another parity check.

fileserver-diagnostics-20260614-1533.zip

Edited June 14Jun 14 by Optimus Prime
clarity

When it's the CPU, it's not detected by memtest; the best way to detect it is what you are seeing, Unraid driver crashing during a parity check or sync, there can also be other issues logged.

That's a bummer. To start a warranty claim, you have to have the batch number from the CPU, which is only printed on the CPU. Before I pull this out of the rack and disassemble it, I figured I'll just use an older machine and temporarily replicate it to an older machine.

I don't care about anything in particular on this machine except my Immich Docker, the Immich_PostgreSQL docker and my Valtwarden Docker. Plus some specific folders on my shares

Is there a way to just "replicate" a system to a new machine? Although in this instance, it'll just be to a single 10TB or 12 TB hardrive without a parity array? I

Actually, I'm thinking about temporarily moving the array from the new machine to an older machine while I deal with replacing the CPU.

Updated migration summary

1. Back up the flash drive.

2. Disable Docker and VMs.

3. For every cache-only share, change storage so it can move to the array.

   Set mover direction to Cache → Array.

4. Run Mover.

5. Verify the cache pool is empty or only has irrelevant leftovers.

6. Confirm the shares now live on the array.

7. Power down cleanly.

8. Move the array data disks and parity disks to the new server.

9. On the new server, assign only the moved data disks as data disks.

10. Do not format anything.

11. Leave the parity disks unassigned initially.

12. Start the array and verify the shares/files.

13. After verification, assign the old parity disks as parity disks.

14. Build parity or run a parity check

15. After machine is fixed, move back into the new machine, then the older machine becomes my backup server

    Thoughts?

That should work.

I have a new data point:

When I try to start a non-correcting parity check through the GUI, nothing appears to happen. When I look at the logs, it shows a correcting parity check started, but it just hangs; the date/time stamp shown in the GUI updates, re-reports the same time and speed as the previous check, and I have to do a hard restart.

Last night, I started a non-correcting parity check using the terminal. It is progressing as expected. And the GUI is reflecting that progress.

That does not seem like a microcode issue to me. I'm still going to try and replace the CPU under warranty, but I think the issue is lying elsewhere. It would be helpful to have more dieas and consideations while I build the backup server.

'

I'd like y'alls thoughts on this.

41 minutes ago, Optimus Prime said:

That does not seem like a microcode issue to me.

It does not, boot in safe mode and start a new check from the GUI, if that still fails, please post new diags.

Before rebooting into Safe Mode, I completed a command-line non-correcting parity check successfully using:

mdcmd check NOCORRECT

That check completed with:

sbSyncErrs=0

sbSyncExit=0

mdResyncCorr=0

all rdevNumErrors=0

I have attached the diagnostics file from after the successful CLI parity check, which shows the server in a good state after that run.

Diagnostics zip attached for the good state: fileserver-diagnostics-20260616-1900.zip

The issue previously reproduced when starting what I believed was a non-correcting parity check from the GUI. In those cases, the syslog showed mdcmd: check correct, and the check would hang at mdResyncPos=0. When the system was in that hung state, I was also unable to complete a GUI-initiated diagnostics collection.

I then booted into Safe Mode and started a non-correcting parity check from the GUI.

This time, the GUI did appear to start it as non-correcting:

mdcmd (36): check nocorrect

mdResyncCorr=0

However, it immediately hung at:

mdResyncPos=0

mdResyncDb=0

The diagnostics show a kernel oops right after starting the Safe Mode GUI parity check:

Oops: general protection fault

RIP: raid6_avx21_gen_syndrome+0x80/0x110

Call trace includes:

check_parity+0x204/0x360 [md_mod]

unraidd+0xedf/0x1280 [md_mod]

md_thread+0xf6/0x130 [md_mod]

I also attempted diagnostics while the system was in this state. The GUI-initiated diagnostics did not complete. Running diagnostics from the terminal eventually produced:

/boot/logs/fileserver-diagnostics-20260616-2042.zip

However, while diagnostics was running, ps showed it blocking at:

/sbin/btrfs filesystem show /dev/nvme0n1p1

with btrfs processes in D state, including get_active_stripe / folio_wait_bit_common, and mdrecoveryd also in D state at get_active_stripe.

fileserver-diagnostics-20260616-2042.zip fileserver-diagnostics-20260616-1900 (ran via terminal).zip

I don't see a cause for the problem; in safe model plugins, it should not make any difference, but maybe there's a config problem somewhere, my suggestion would be to first upgrade to 7.3.1, if the issues persists there, try redoing the flash drive, backup the current one first and then recreate it using the USB tool and just restore the bare minimum, like the key, super.dat and the pools folder for the assignments, also copy the docker user templates folder (\config\plugins\dockerMan\templates-user), if all works you can then reconfigure the server or try restoring a few config files at a time from the backup to see if you can find the culprit.