plunderisley

Just to post an update: I did a full BIOS update, re-did the settings in the BIOS for the Ryzen CPU (cstate and other recommend changes) and also lowered the max TDP of the CPU. Waited 14+ days and did a parity check (last one was months ago). Finished with 0 errors. Seems it's stable now. Maybe the BIOS version had issues.

I'll update the BIOS to the latest version and go through the c-state fix info again and configure it. I did a memtest86 a few months ago and for about 24hrs of running there were no issues. All the other attached devices seem to be fine. The stuck docker container on a boot loop was before the update.

Attached are the syslog for this month. I don't see anything there of any mention of the last night (well would have been around 4am 4th Aug) server lockup. I'm quite sure I did all those c-state changes before but I will double check. Sunday morning the docker containers update. I did the 7.3.2 update sun afternoon or evening time. It is a 5800x Ryzen 7 and a ASRock X470 mobo.

I updated to 7.3.1 a month or so ago and the server was running fine. A few days ago I patched it to the 7.3.2, rebooted fine and all worked. Last night, the server seemed to lock up and I was unable to SSH in to reboot it, and had to reset it (unclean shutdown). No idea why. the diag are attached.

Thanks for checking. I'll keep an eye out on the docker container and see if any more out of memory messages pop up.

Attached.

I tried the reboot and it did reboot (unclean apparently) but its working fine now. I stopped the bambu docker (its the 3d printer one) from booting up. Only odd message I received when rebooting (well other than the unclean shutdown and to do a parity check) is: Cache pool BTRFS missing device(s) CT1000P1SSD8_20512C63F770 (nvme0n1) But after I entered the password and the array started, it shows fine in the web ui (normal operation, 0 errors, SMART 0 errors) so IDK if it's an error because the array wasnt unlocked yet or something else....

I updated to 7.3.1 some weeks ago and all seemed well. The other day I added a share and tried to set the SMB users and it wouldn't save. I tried to do a reboot, but I can't stop the array. Attached are the diagnostics. I don't want to force a shutdown if it'll cause issues cause I can still access the server now. /usr/local/sbin/mdcmd stop /usr/local/sbin/mdcmd: line 35: echo: write error: Device or resource busy /usr/local/sbin/mdcmd stop /usr/local/sbin/mdcmd: line 35: echo: write error: Device or resource busy

hmm not sure. How can I check if its the audio? It shouldnt be skipped as I marked it to transcode even if same format.

I had a few movies transcode to H265. I noticed that when the transcoding runs, the CPU cores are maxed out but nothing is happening on the GPU side (even though I can see unmanic loaded into the GPU). I did set the --runtime=nvidia and the correct UUID. In the plugin for transcoding, it does see the GPU. But it doesn't seem to use the GPU. How can I fix this? Also I noticed the transcoded quality isn't great. GPU is a GTX1080 8GB Under global plugin settings: Standard config mode max input stream buffer 2040 video codec - HEVC/H265 force transcoding checked NVENC-hevc_nvenc The nvidia device selected HW decoding - NVDEC/CUDA - use GPU hardware Quality - P5 Tune - HQ Profile - Auto Encoder ratecontrol - Auto keep same container checked

Maybe its some bug in the 7.2.3 version? I could run a parity scan again in a few days and see if it catches anything, but I'm not sure if that's worth it to stress out the drives again (given each parity check is 20TB)

Yup. syslog.log I read the first post on that unclean shutdown and changed the disk settings from 90 to 420sec and VM to 300sec. It does make sense, given I have a ton of docker containers running (though when I did run the scan, I only had 2 containers up and rest were stopped as not to interfere with the parity check)

Attached are: diagnostics that I grabbed when I started the write correction (after the parity scan without write correction and no reboot).zoidberg-diagnostics-20260130-0006.zip the diagnostics after the write correction finished.zoidberg-diagnostics-20260131-1312.zip I shutdown the server, opened it up to check and re-seat the SATA cables, and booted it up. I got a unclean shutdown detected (no idea why, as I pressed the shutdown button on the main web ui and it did say it shutdown). I attached those diagnostics too. zoidberg-diagnostics-20260131-1404.zip I'm not sure if I need to do another whole parity scan, as I already did 2 and the previous 1375 errors were fixed.

Shoot, already started the write correction. I did save a diagnostic just now (7 sync errors corrected, 845GB/4.2% completed) and I'll do one once it'll be done sometime tomorrow night/next morning.

The parity check completed. Parity Check Tuning Manual Non-Correcting Parity-Check finished (1375 errors) Elapsed Time 1 day, 8 hr, 56 min, 9 sec, Runtime 1 day, 8 hr, 56 min, 9 sec, Increments 1, Average Speed 168.7 MB/s I'll run a correcting parity check now and fix those errors. It seems the issue was probably caused by either a controller issue or some issue with AMD Ryzen and unRAID (there was some issues iirc with those).

Okay. If it happens again, I'll do a diagnostics before I reboot. (it was a panic shutdown as I've never seen that before) Right now its 1.5hrs into a parity-check (5.7%) and 7 sync errors found (in the beginning of the scan). The SATA controller is on the motherboard.

memtest I've done 2 months or so ago when I added 2 additional sticks and it passed fine (did multiple passes over it to make sure it was good). I'm using the XMP profile that showed in the BIOS for the RAM sticks. DIMM 0: Unknown CMK16GX4M2A2666C16, 8 GiB DDR4 @ 3200 MT/s DIMM 1: A-DATA Technology AX4U320016G16A-BB10, 16 GiB DDR4 @ 3200 MT/s DIMM 0: Unknown CMK16GX4M2A2666C16, 8 GiB DDR4 @ 3200 MT/s DIMM 1: A-DATA Technology AX4U320016G16A-BB10, 16 GiB DDR4 @ 3200 MT/s I remember I did change the c-state in the BIOS back in May or June (?) when I was first setting up the server as I had problems with it. Since then it has been running fine. Unless somewhere it lost the setting or it was never configured correctly.

Oh I do have that now once the array is up. syslog.txt

Multiple cables.

Okay. My thought here is if this is a hardware issue (say motherboard is dying or something else), and the parity check goes crazy again, I can then replace the motherboard or psu as I'd assume that would be the cause (unless Im missing out on something)

Okay. I got the array up. I'll stop all the docker containers to make sure nothing is running in the background. Should I do a write correction parity-check (assuming that is what you meant) or to be safe first do a check parity before doing a write corrections one?

I'm a bit of a noob with unraid still. Assuming both disks are OK and unraid parity check just went crazy (who knows if it was a controller mobo issue, or some docker container also trying to do something the same time and messed something up as I am running it on AMD), what would be the exact steps to do the new config and get this back up online?

zoidberg-diagnostics-20260128-1058.zipzoidberg-diagnostics-20260128-1050.zip Also, all this happened during a parity scan. I'm leaning more towards a failure of the controller or some motherboard issue.

Rebooting gives me this No idea what to do now or how to proceed. I don't believe 2 drives failed at the same time. Added the diagnostics zoidberg-diagnostics-20260128-0205.zip

A parity check (the quarterly one) started running and about 20% in I got a notification os multiple drives errors and failing. I have no idea how this happened or what could have caused it. Everything has been running fine now and I dont see how every drive could fail like this. I stopped the array and it looks like this: This would be absolutely catastrophic if all the drives failed. What can I do to try and fix this or diagnose the problem?