Top Of The Day To All

Last weekend, I replaced my two 12 TB parity drives with a 16 TB drive because I'm getting ready to add more 16 TB disks to the array. Also, I added a SAS card to add external drives to the array. Since doing this, I haven't been able to complete a parity check; the system comes back offline. And I have to restart the system by clicking the Start button or doing a hard restart. This morning, I went to log in to the array, had to do a hard restart, and found that the last digit in the IP address had changed from 136 to 135. This is something new.

I am running OS 7.3.2 on the array. Here are my diagnostics for you. Please keep your replies simple, because I won't know what to do or what to look at. Thank You, Respectfully John

olympus-diagnostics-20260926-1102.zip

I dont see anything relevant logged, considering enabling the syslog server and post new diags next time it acts up.

IP changing is because you are using DHCP instead of having assigned a static IP. This is normal.

Thank you

Respectfully

John

Well, it did it again, and the only thing I did was remove the parity check plugin.

Any help with this problem would be greatly appreciated.

Respectfully

John

olympus-diagnostics-20260928-0123.zip

The diags contain a hardware error that was not present in your first upload. This gives us something more specific to investigate.

The error could involve the processor, memory, motherboard, BIOS settings, or power supply. It does not prove that your processor needs replacement.

Your new parity disk has not finished building, so the array currently lacks parity protection. Please wait before adding more drives.

Recommend to start with these steps:

1. Under Settings → Syslog Server, enable Mirror syslog to boot drive temporarily. Your current settings enable the log receiver, but do not preserve this server’s own log across crashes. Disable mirroring when troubleshooting is complete. (https://docs.unraid.net/unraid-os/troubleshooting/diagnostics/capture-diagnostics-and-logs/)

2. Tell us whether XMP, Precision Boost Overdrive (PBO), or CPU undervolting is enabled in the BIOS. If you are unsure, let us know before changing anything.

3. Run Memtest86+ from the Unraid boot menu for at least four hours, preferably overnight. Report any errors. Memory testing should use default memory settings.

Please also provide the power supply’s model and wattage, and the exact SAS card model you added.

The IP address change is separate: your server uses DHCP. A DHCP reservation in your router can keep its address consistent.

Thank you and I hope this parity check will work. Then I will start doing the troubleshooting you requested.

Respectfully

John

8 hours ago, wilekcmc said:

Well, it did it again, and the only thing I did was remove the parity check plugin.

This plugin should never cause the server to crash. If you are getting issues during a parity check then you almost certainly have some other issue (quite likely hardware related).

Ok,

The XMP was set to Auto, which is its default setting.

Quickboot is disabled

CPU voltage is set to auto (never overclocked or undervolted)

PSU was bought in Nov 2020 and is a Corsair HX Series, HX1200, 1200 Watt, Fully Modular Power Supply, 80+ Platinum Certified, Model Number: CP-9020140-NA

SAS Card is a BROADCOM 9305-16E SAS/SATA 12Gb/s 16P EXTERNAL PCIE 3.0 HBA 05-25704-00

Just started to run the memory test; it's 11:16 am Japan time. Will let it run till tomorrow when I get back from the gym (around 10:00 am)

Let me know if you need anything else.

Respectfully

John

Thanks John, that's all very helpful.

Your settings sound like stock, which is good. Your power supply has more than enough capacity for this server, and the SAS card is a good model that Unraid supports well. Nothing you listed stands out as the cause.

When the memory test is done, please tell us:

1. Whether it passed or showed any errors (errors show in red).

2. Whether the parity build finished this time. You can see this under Main → Array Operation, or in the parity history there.

After that, if the memory test passes, the next steps are some BIOS changes. You don't need to do them now; just so you know what's coming:

- Make sure Precision Boost Overdrive (PBO) is set to Disabled and that no Curve Optimizer values are set. On ASRock boards these are under Advanced → AMD Overclocking.

- Set Power Supply Idle Control to Typical Current Idle. On ASRock this is usually under Advanced → AMD CBS → CPU Common Options.

- Update the BIOS. Yours is from 2021, and ASRock has released newer versions for the X570 Taichi since then. Do this with the array stopped, and don't turn the server off while it updates. An update resets BIOS settings, so check the two settings above again afterwards.

If the server crashes again after those changes, please post new diagnostics right after it restarts. The syslog mirror to the boot drive you enabled will save what happened just before the crash. Don't add any new drives until the server is stable and the parity build has finished.

Ok, just finished the memory test. It ran for 21 hours and 58 minutes, and everything passed.

I also did the BIOS update and made sure everything was set correctly.

Now I am going to bring the array back online and run a parity check; I am praying it goes well.

Dumb question: should I have used the new config tool when I replaced the parity drives? I have no clue what this tool is used for.

No, you did not need to use New Config for this parity replacement. Removing the second parity disk does not require it either. New Config resets the disk configuration; it would not fix the hardware error we found.

Nearly 22 hours without memory-test errors is encouraging, although it does not rule out every hardware problem. Please also tell us which BIOS version you installed.

Your last diagnostics showed that the replacement parity disk still needed to finish building. A parity build writes the protection information; a parity check checks information already written.

If the build is running now, let it finish and tell us the result. Leave the disk assignments unchanged, and wait before adding more drives.

Please make sure Settings → Syslog Server → Mirror syslog to boot drive is enabled temporarily. If the server crashes again, attach new diagnostics after restarting, along with the saved syslog.

Thank you for the info on the new config and how it works.

The BIOS version is 5.80, dated 2/42026.

I'm currently trying a parity check; I'll let you know what happens.

Thanks

John

Well, the parity check failed again. Here are the diagnostics for it.

I have no clue what is going on.

I have 9 new drives I want to use, but I can't, sorry just venting

olympus-diagnostics-20261002-0810.zip

The good news is that the syslog mirror worked, so this time we can see what happened. The parity build ran for about 36 hours without any errors. Then, sometime after 11pm, the server simply froze. It logged no error message at all, and it didn't record the hardware error we saw last time. When a server stops like that, the cause is almost always hardware or BIOS settings, not Unraid or your disks. Your disks look healthy.

Let's change one thing at a time so we can tell what fixes it:

1. Check Power Supply Idle Control. A BIOS update resets settings, so please go into the BIOS and check that Power Supply Idle Control is set to Typical Current Idle. On your board it's usually under Advanced → AMD CBS → CPU Common Options. Please tell us what it was set to before you changed it.

2. Remove the SAS card for now. Shut down the server and take out the 9305-16e. Nothing is connected to it yet, and the problems started when you added it. You can put it back once the server is stable. Leave everything else as it is.

3. Start the array and let the parity build run. It starts again from 0% after a crash, so it will take about a day and a half. Please don't add any drives yet.

If it freezes again:

- Before you restart it, look at the monitor connected to the server (if you have one) and tell us whether there's anything on the screen.

- Then post new diagnostics like you did this time.

- The next step would be to disable Global C-state Control in the BIOS.

I know you want to use those 9 new drives. Getting the server stable first is what protects the data you already have.

Sir,

The Power Supply Idle Control is set to Typical Current Idle, so no change was needed, and I removed the SAS card from the system. As soon as it boots up, I will try another parity check.

Thanks for your help with all of this.

Respectfully

John

That was wired when I logged into start the parity check the arry was off line and I had to rest my drived to there correct postitions. Then I started the arry and Parity but arry names and a few small things chaged, it went back to light mode, name of the arry changed. strange

That is weird; if you didn't reboot yet, please post new diags.

Sorry, I already have it on Pariet Sync; we will know in a day and a half.

Thanks.

I woke this morming and found the arry off line, went to download the diagnostics for it and I lost the login screen. Had to do a hard restart to get it to login.

Here is the diagnostics for it.

I have no clue to what is wrong with it.

gin.zip

I just tries to login to the sever but there was no response from it. I had to do a hard restart to get it going again, here is the log for you to review.

I have never had this problem before.

Doing a soft shut down until some can tell me what is going with it.

Thanks

tower-diagnostics-20261003-1424.zip

Thanks for posting both sets of diagnostics. They tell us much more this time.

The hardware error came back. It's the same error we saw on September 28, from the same CPU core, with exactly the same values. This happened even after the BIOS update, which also updated the CPU microcode. I also see you removed the SAS card, and passed a 22-hour memory test. So the most likely cause is now the CPU itself, specifically one of its cores. I can't prove that from the logs alone. A different CPU is the test that would confirm it.

What I recommend:

1. If your 5950X is still under warranty, contact AMD support about a replacement. Tell them the system has repeated "machine check" errors on the same core at stock settings. If it's not under warranty, try a different AM4 CPU if you can borrow one, or replace it.

2. Until then, keep the server off, or use it as little as possible. Every crash restarts the parity build and risks damaging the boot USB again.

3. Don't add the new drives yet. I know that's frustrating, but it's the safest thing for your data right now.

Why your settings changed: Because of all the forced restarts, the files on your boot USB were damaged. Unraid repaired the USB when it started, but some settings files were lost in the repair. That's why the server name, theme and disk assignments went back to the defaults. Your reassignment matches the original slots exactly, so you did that correctly. Your data disks look healthy.

When the server is on, please fix these:

- Settings → Identification: set the server name back to what it was.

- Settings → Date and Time: set the time zone to Tokyo again, and enable NTP so the clock stays correct.

- Settings → Display Settings: set the theme you prefer.

- On the Main page, click your boot USB and use Flash Backup. Keep the backup file safe on your PC, and make a new one after any settings change.

- You can delete the files named FSCK0000.REC to FSCK0006.REC from the boot USB. They are only leftovers from the repair.

When you have a replacement or test CPU installed, let the parity build finish and post new diagnostics. We can go from there.

Sir, Thank you and the system will stay off, I will start looking for a new cpu, is theres any around and not a arm and a leg for them.

Thanks again and I will let you know when I get the cpu installed.

Respectfully

John