February 4, 20179 yr This is my first server build, first time using Unraid, and I don't have a log, so I appreciate your patience. When I start the array, the parity sync begins and hovers around 98 mb/sec for the first 10 minutes or so. Over the next couple of minutes the speed drops to around 3 mb/sec. At around 20 minutes, it becomes unresponsive - Attempting anything in a browser over the network will now timeout, a keyboard plugged directly into the server no longer works. The only thing I can do is a hard shutdown. On restarting, everything works fine again until I try to start the array and the process repeats. I'm afraid I don't know how to get a log before the shutdown.
February 4, 20179 yr This is my first server build, first time using Unraid, and I don't have a log, so I appreciate your patience. When I start the array, the parity sync begins and hovers around 98 mb/sec for the first 10 minutes or so. Over the next couple of minutes the speed drops to around 3 mb/sec. At around 20 minutes, it becomes unresponsive - Attempting anything in a browser over the network will now timeout, a keyboard plugged directly into the server no longer works. The only thing I can do is a hard shutdown. On restarting, everything works fine again until I try to start the array and the process repeats. I'm afraid I don't know how to get a log before the shutdown. Restart, stop the array before it crashes again, Install the fix common problem plugin, toss it into troubleshooting mode, and then start the parity sync and after the crash post the last dated diagnostics in the logs directory and the file FCPsyslog_tail.txt on the flash drive
February 5, 20179 yr Author Restart, stop the array before it crashes again, Install the fix common problem plugin, toss it into troubleshooting mode, and then start the parity sync and after the crash post the last dated diagnostics in the logs directory and the file FCPsyslog_tail.txt on the flash drive Logs attached. FCPsyslog_tail.txt coop-diagnostics-20170205-0649.zip
February 5, 20179 yr Restart, stop the array before it crashes again, Install the fix common problem plugin, toss it into troubleshooting mode, and then start the parity sync and after the crash post the last dated diagnostics in the logs directory and the file FCPsyslog_tail.txt on the flash drive Logs attached. Perfect... (Finally a FCPsyslog_tail that showed the probable problem that wasn't present in the diagnostics) Probably related to this: (this was actually going to be the next check going into FCP) Feb 5 07:14:16 COOP kernel: mce: [Hardware Error]: Machine check events logged Unfortunately, it's meaningless by itself -> could be pretty much anything hardware related (temperature, memory, etc etc etc) If you install the nerdpack plugin (once again stop the parity check so that there's time to do this), there is an available module within it called mcelog-128-x86_64-1.txz Install that, then toss FCP into troubleshooting mode again, and start the check again wait for the crash and then upload the files again. There should be more information in the logs about what is causing the issue AFAIK
February 5, 20179 yr Author I installed nerdpack and turned on the mcelog-128-x86_64-1.txz module, and tried again with FCP in troubleshooting. I've attached the logs. I don't know if this is important but in the last set of tests, it performed as I explained earlier (Parity sync slowing down and eventually crashing after 20-30 minutes). In this set of tests it crashed within 5 minutes of the parity sync--which it does occasionally. FCPsyslog_tail.txt coop-diagnostics-20170205-0803.zip
February 5, 20179 yr Nothing got caught that time... so down to guesses - Run memtest from the boot menu for at least one pass - Check to make sure nothing is impeding the cooling fans from spinning - Disable VMs in Settings - VM Manager Also, does anything show up on the local monitor for the server when it crashes? Take a pic if you can
February 5, 20179 yr Author Memtest also worked fine until around the 30 minute mark and then it froze. It doesn't look like the cpu is overheating and all the fans continue to run. I guess the next step is to try 1 ram stick at a time and then start swapping out components?
February 5, 20179 yr Memtest also worked fine until around the 30 minute mark and then it froze. It doesn't look like the cpu is overheating and all the fans continue to run. I guess the next step is to try 1 ram stick at a time and then start swapping out components? Yup... What I would do is pull out everything from the motherboard also. Any extra video cards, etc to run a pass with memtest. And then start adding components back one at a time. When you get to a failure point, its either going to be power supply or the component. BTW, without going through diagnostics again, what is the make and model of the ps and the # of drives you've got...
February 5, 20179 yr Author It's a Seasonic Power Supply 650W SS-650HT, bought used. Trying to get things going with just 3 drives total.
February 6, 20179 yr Author I appreciate your help, I know this isn't really a hardware forum but I haven't been able to solve the issue. I ran memtest with each stick of ram individually with everything else disconnected from the mb, each stick passed. I tried two sticks at once, they both passed. I tried all four sticks, and the system crashed. Thinking it might be some faulty slots on the mb, I tried the parity sync with just the two sticks in that passed memtest together, and it crashed. I tried swapping out the power supply, still crashed. I guess it comes down to the motherboard or the cpu - is there a way to test either to avoid exchanging/swapping them out ?
February 6, 20179 yr I tried two sticks at once, they both passed. I tried all four sticks, and the system crashed. That by itself is pretty common. Consumer motherboards walk a fine line when it comes to running too many physical memory chips at once, as soon as you get some age on the parts, there is too much electronic noise in the memory system to read the bits reliably. Sometimes replacing the memory with more energy efficient chips will solve it, sometimes the power supply is a little too noisy, either the power supply that you commonly think about, or the motherboard chips that regulate the voltage directly to the memory. So... if you value your data and sanity, I would strongly recommend thinking about moving to a newer generation system. Using server grade parts with registered ECC memory makes a lot of sense if your time is valuable. It's no fun chasing gremlins, especially when those gremlins threaten to corrupt your valuable data.
February 6, 20179 yr Author So... if you value your data and sanity, I would strongly recommend thinking about moving to a newer generation system. Using server grade parts with registered ECC memory makes a lot of sense if your time is valuable. It's no fun chasing gremlins, especially when those gremlins threaten to corrupt your valuable data. It's a new supermicro board with ECC memory. The Xeon cpu is 4 years old and the board came out 3 years ago - I figured it would be new enough for my budget.
February 6, 20179 yr ECC isn't the critical part for the problem you are seeing, it's the registered part. Registered RAM is typically on E5 Xeon's, I don't think I've seen any E3 systems with registered. I hadn't seen your system description in any of your posts, so given this new (to me) information, I'd place my money on the motherboard being the problem, unless you are using RAM not on Supermicro's tested and approved list.
Archived
This topic is now archived and is closed to further replies.