LumberJackGeek

I have shared multiple syslog files on this thread, you've directed me to a link but have failed to explain what I am doing wrong. I pointed you at an exact file name to open up and you said you can't be bothered to find it, I gave you the file name, and that was all that was in that file. You may be an expert, and you may be a moderator, but your level of helpfulness on this specific issue right now isn't there for either of those titles, if you don't wish to help me any further, please just say so, or walk away, that's fine.

PS, i replaced the CPU today, but it sounds like that might have been unnecessary...?

Well i got it to rebuild the drive, and then when i did, i rebooted and it tried saying the disk was the old one again, so i did the new config and have been trying to resync parity for the last week but it's been hanging again trying to do so. i have shared multiple rounds of diagnostics, if what i have shared is not enough, please let me know what is enough? exact steps of what you are looking for would be appreciated. how confident are you that this is not a hardware problem anymore? it hangs in a variety of places, sometimes it hangs during safe mode, sometimes it hangs before bringing the array online, but more often than not it hangs doing the parity computation. it can hang 10 minutes into it, or 10 hours later, there's no time duration or % pattern that i have noticed.

Replaced motherboard today, still happening.

Panic#2 Part3 <6>BTRFS info (device loop2): first mount of filesystem fd9bd8af-d3b4-4fec-a4d8-55e7b9dff8b7 <6>BTRFS info (device loop2): using crc32c (crc32c-lib) checksum algorithm <6>BTRFS info (device loop2): turning on async discard <6>BTRFS info (device loop2): enabling free space tree <4>kvm: Running KVM with ignore_msrs=1 and report_ignored_msrs=0 is not a <4>a supported configuration. Lying to the guest about the existence of MSRs <4>may cause the guest operating system to hang or produce errors. If a guest <4>does not run without ignore_msrs=1, please report it to [email protected]. <4>mdcmd (36): check <4>md: recovery thread: recon D4 ... <4>------------[ cut here ]------------ <2>kernel BUG at drivers/md/unraid.c:1622! <4>Oops: invalid opcode: 0000 [#1] SMP NOPTI <4>CPU: 15 UID: 0 PID: 18261 Comm: mdunraidd0 Tainted: P O 6.18.33-Unraid #1 PREEMPT(voluntary) <4>Tainted: [P]=PROPRIETARY_MODULE, [O]=OOT_MODULE <4>Hardware name: ASUS System Product Name/ROG MAXIMUS Z690 HERO, BIOS 4001 10/07/2024 <4>RIP: 0010:unraidd+0x12ce/0x13d0 [md_mod] <4>Code: 83 3d b9 70 3a 06 03 7e 17 41 8b 57 98 48 8b 73 20 44 89 e1 48 c7 c7 21 63 43 a8 e8 1c ea 20 df 41 f6 87 69 ff ff ff 02 75 02 <0f> 0b 48 8b 43 20 49 03 46 18 41 c7 47 b0 00 10 00 00 49 89 47 a8 <4>RSP: 0018:ffffc900055cfd30 EFLAGS: 00010246 <4>RAX: 0000000000000000 RBX: ffff88812483c9b0 RCX: 0000000000000000 <4>RDX: 0000000000000000 RSI: ffffffff8335f240 RDI: ffff888101c6a038 <4>RBP: ffffc900055cfe40 R08: 0000000000000000 R09: 0000000000000000 <4>R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000002 <4>R13: ffff88812483c9a0 R14: ffff88811d74d3b0 R15: ffff88812483ccd0

If it were hardware failing, I would expect the hang to be in various locations, various offsets, but 24 times at the same offset? That seems suspicious, no?

I had AI review my logs, completely ack that it could be wrong, but: But the persisted crash dumps reveal a clear, recurring root causeAcross the saved pstore/crash captures, the same kernel BUG repeats 24 times with an identical signature: kernel BUG at drivers/md/unraid.c:1622! Oops: invalid opcode — Comm: mdunraidd0 — RIP: unraidd+0x12ce [md_mod] md: recovery thread: recon D4 ...This is a BUG_ON assertion failing inside Unraid's own proprietary md driver (md_mod), in the mdunraidd0 kernel thread. Every occurrence is tied to a parity/reconstruct operation — specifically recon D4 (disk-4 rebuild/sync) appears 60 times in the captures. Disk 4 = sdq (the OOS 24 TB drive). This matches the evidence file you already saved: CRASH-EVIDENCE-unraid-md-bug-20260630.zip.

I see them in the diagnostic, check this file here: pstore-20260630-202155/dmesg-efi_pstore-178244749403002 RAM has passed a memory check. What can I do to prove in or out CPU? I've seen other posts on these forums with folks being told similar symptoms are hardware, hardware, hardware, and then oh look here's an update that fixes.

So far I have spent ~$900 replacing hardware trying to fix this issue.

Additionally, I replaced the USB flash drive the OS was booting from today and switched over to an NVMe drive, started recomputing parity and I went down several hours later.

CRASH-EVIDENCE-unraid-md-bug-20260630.zip

replace the drive, still having the same issues. I keep seeing this in logs: kernel BUG at drivers/md/unraid.c:1622! RIP: unraidd+0x12ce/0x13d0 [md_mod] Comm: mdunraidd0 preceded by: mdcmd (36): check → md: recovery thread: recon D4 ... Any idea what this means or if it's related to my problem?

Correct, that previous session was NOT safe mode, the only time I have hung in safe mode is sometimes when first booting into it after a hang, it will hang again but this has maybe only happened twice. The VM is shut down, but the manager not disabled, is that good enough? And I am running just Plex and tautlli effectively and it still happens. I ordered a replacement drive to see if it's the drive that I am trying to put in the array, but there are no SMART errors so I had been avoiding, and the drive is 50% more expensive than when I originally paid for it so I wanted to avoid doing this, but I need to test it.

dataserver2-safemode-diagnostics-20260624-1448.zip Hung again this morning after rebooting recovering from another hang. I rebooted into safe mode and gathered these logs, so the syslog-previous should be from the session that hung. So far I have: Replaced all drive power cables Replaced my HBA Ran memtest, all clear Removed the unassigned devices plugin Any other recommendations?

Yeah I mean it's literally hanging at the end of the trace. I have replaced my HBA, and all of my power cables to my drives, and it just went down again. I will pull the logs tomorrow and share.