January 12, 20188 yr Before anything, I should note that I'm on a Ryzen build, so I've been on 6.4 rc's since the one that fixed the Ryzen issues. It was stable until...well until it wasn't, but it could just as easily have been a fluke. I was having some issues with my server that ended with me rebuilding my USB drive. I simply flashed a new, up-to-date 'next' build, and copied over everything from the config folder. Everything's working great except it just stops working every so often, just like it did when I was running 6.3 on the Ryzen build. This leads me to suspect some regression perhaps? But if I'm the only one having issues, that's probably not it. I have a screen session tailing the syslog out to a file. Some questions about this for diagnostics: Would it be preferable to have it outputting to a disk, or is outputting to a share fine? I have it writing to a share location right now, but it's just occurred to me that disks (/mnt/disk1) may be present when shares aren't (when the array goes down, but before the system locks up). Is this the case? Second, are there any other logs I should be recording, or any log levels I can adjust to make the diagnostics more useful?
January 12, 20188 yr Have you read through the post below? In essence, if C-State is disabled in the BIOS, it fixes most stability issues with Ryzen. Prior to upgrading to rc20a, my system was stable for 30 days. https://lime-technology.com/forums/topic/55150-anybody-planning-a-ryzen-build/
January 12, 20188 yr Author I have kind of a cheap motherboard, and no GPU to plug a monitor in at the moment -- does zenstates --c6-disable in the go script get the job done?
January 14, 20188 yr Author Just to update -- it appears that yes, zenstates --c6-disable in the go script before emhttp gets the job done. Anyone reading this know of any downsides to keeping this as the permanent solution? Can always remove it if/when Unraid supports C-states.
January 14, 20188 yr Author Hmm, is that not the case when it's disabled in the BIOS? Honestly, probably upgrading this machine within a year or so anyway, with this board being relegated to router/VPN duty. Next build I'll do my research -- this one was an emergency purchase to replace a dead board, and I got the cheapest everything I could. Remarkably, the brand new (at the time) Ryzen 3 was the cheapest chip+board I could find locally.
January 16, 20188 yr Author This fix has stopped working, and it's crashing as before, after just a couple hours of idle. Effectively, this means it runs for the inevitable parity check (because I have to hard shutdown) around 10 hours, then a couple hours, and it's gone. Things seemed to get less stable when I added a cache drive, but I think that could have been a fluke. I removed the cache drive, and it still crashed (today) This time, however, I have logs being saved! I made a quick little script that runs at array start to save logs to the USB drive. I'm at work right now, and only know it crashed because openvpn won't connect, but I'll check the log when I get home -- what should I be looking for if it's a Ryzen issue, vs another one?
January 20, 20188 yr Author She's back! I was getting really frustrated and ready to THROW money at this thing, just thinking screw it, I'll buy new hardware. I couldn't get either the built-in graphics or a PCI-E GPU to produce anything on a monitor for a while. I ended up throwing in a different GPU and *finally* it came up. Turning off C-states in the UEFI settings made things work -- stable for a day now with near-0 activity (which is when it would crash quite quickly, which makes sense given what C states do). All that to say, I don't thing the zenstates hack works reliably, and I don't suggest anyone use it as a permanent fix.
Archived
This topic is now archived and is closed to further replies.