• Content count

  • Joined

  • Last visited

  • Days Won


Pauven last won the day on July 5

Pauven had the most liked content!

Community Reputation

39 Good

About Pauven

  • Rank
    Advanced Member


  • Gender
  • Location
    Atlanta Metro Area
  1. Anybody planning a Ryzen build?

    I was the original discoverer of the Ryzen stability issue and C-state solution. My server is extremely susceptible to the C-state issue, typically crashing in 4-8 hours when the issue is present. I'm running 6.4.0-rc7a, with C-states enabled, and my uptime is 52 days. I have avoided all of the recent 'Really Close' releases since 7a, as the changes just seemed too scary for me to be a guinea pig. I think it was the introduction of the block level device encryption. I don't plan to use it, but I have nightmares thinking that a beta version could somehow misbehave and accidentally encrypt my precious data, so that I never get it back. I know the odds of that happening are pretty much zilch, though if it could happen it would likely happen to me. I'm waiting for the next stable public release. Anyway, perhaps something has changed since 7a that lost the fix for the Ryzen C-state issue. Paul
  2. I've had lots of similar issues lately, also on -rc7a. The only solution I've found is to boot in safe mode. I think a plugin is somehow breaking this functionality. I'm currently running in safe mode for this very reason, and a parity rebuild is in progress, so at the moment I can't tell you what plugins I normally run. I'll check later.
  3. Are your freezing issues occurring with 6.4.0-rc7a, or a different version? Does disabling "Global C-state Control" in your BIOS fix the issue?
  4. Anybody planning a Ryzen build?

    Thanks Greygoose! I just reached 50+ hours uptime on 6.4.0-rc7a with C-states enabled. Looks like Lime-Tech may have solved the stability issue, good job guys! With C-states enabled, Idle wattage has dropped 10+ watts. My UPS only reports in 10.5w increments (which is 1% of the 1050w power rating), so actual savings are likely somewhere between 10.5w-21 watts. From earlier testing with a more accurate Kill-A-Watt, the actual delta between C-states enabled & disabled was between 12w-18w. Idle temps have dropped 2-3 degrees C on both CPU (41C) and System (36C). Not as much as I had hoped, but I think my expectations were off. I did a lot of initial testing with the case cover off, and temps have unsurprisingly increased simply from closing the case, as case fans are on lowest speed (three 120mm fans, 1000 RPM @ 35% PWM), and they have to suck air past the HD's, so very little airflow at idle. The CPU fan speed profile is set to 'Standard' in the BIOS. At max case fan speeds (2750 RPM), idle CPU temp easily drops to 35C and System to 30C, but the higher fan speeds consume an extra 10+ watts and make lots of noise. As a compromise, I just changed my minimum case fan speed to 1400 RPM @ 50% PWM, which is much more quiet and energy efficient than full blast, but still improves my idle temps a couple degrees over the slowest fan speeds: 39C CPU, 34C System. I'll probably change the CPU fan profile from Standard to Performance in the BIOS to see if that drops the 5C delta over ambient a bit, but other than that I think I'm done. I'm happy to have idle temps back in the 30's, at reasonable fan speeds/noise, and with idle watts back to a more reasonable level. Paul
  5. That again aligns with my experience. Under -rc7a, assigning the drive and starting the array once weren't enough. I had to stop/start multiple times, and the last reboot really helped sync things up. I also had Mover issues, as the share.cfg file had lost some settings related to the cache drive. Be sure to check Mover on your server, and if you're having problems, the solution was documented in the forum link in my previous post above. I can't tell if it is the new GUI misreporting what the system is doing (possibly caching old info), or the system misbehaving. Either way, this is the first time I've experienced this type of behavior in 8+ years of using unRAID. Paul
  6. Anybody planning a Ryzen build?

    That's not a bad idea. I've been using the same USB stick for 8+ years, since the beginning when I started with 4.5 beta4 (with its brand new 20-disk limit). How's that for a flashback. Though I've certainly wiped it on occasion over the years. Most recently I think for the 6.1 branch. Now that I've finally got things settled, I'm gonna let it chill as-is. If more problem crop up, this will be high on my trouble-shooting list. As far as dealing with the potential corruption, I might just have to start from scratch and rebuild my configuration if I wipe the drive. Otherwise, I'm simply restoring potentially corrupted files. Thanks. Paul
  7. I'm running this now on my Ryzen build. New drivers are greatly appreciated, as is the fix for assigning the cache drive. I did experience at least 1 Kernel Panic, snapped a pic you can see here (plus a write-up on my general experiences with -rc6/-rc7a): Huh, I had kinda noticed that the temps weren't displaying on my NVMe drive, but I was attributing that to my general cache drive assignment problems. Now that those are resolved, I can confirm that temps are not displaying. A very important configuration change has been applied that may eliminate the need for disabling Global C-state Control. My system typically crashes in a matter of hours with C-states enabled. I'm testing this now. Early reports are promising, though absolute confirmation may take some time. Here's the change (quoted from the release notes above): If you are looking for better VM performance, that will probably have to wait on fixes destined for a newer Linux kernel, though there may be some general improvements in 4.12. This is out of Lime-Tech's control. I had similar experiences, though technically mine started on v6.3 with my new Ryzen build when I swapped out my cache drive - I could never assign the new one until -rc7a. Thank you Lime-Tech. Paul
  8. unRAID OS version 6.4.0-rc6 available

    So ultimately -rc7a did resolve the issue, though not without some headaches along the way (including a Kernel Panic). Posted details here: Thanks for all your help! Paul
  9. Anybody planning a Ryzen build?

    Okay, multiple findings. First, when I checked on my server this morning, I found a Kernel Panic on the console screen, and the system was fully hung. Here's a pic: I restarted in Safe Mode again, started the array, and checked the share.cfg file. shareCacheEnabled was still missing. I stopped the array and went to the Settings/Global Shares panel. I couldn't directly apply "Yes" to "Use cache disk:", as it was already on "Yes" and wouldn't let me Apply it. I set it to "No", Applied, then set back to "Yes" and Applied. Now the share.cfg file got updated with the shareCacheEnabled="Yes" line, plus what appears to be several additional lines that must have also been missing. Here's the new file contents: # Generated settings: shareDisk="e" shareUser="e" shareUserInclude="" shareUserExclude="" shareSMBEnabled="yes" shareNFSEnabled="no" shareNFSFsid="100" shareAFPEnabled="no" shareInitialOwner="Administrator" shareInitialGroup="Domain Users" shareCacheEnabled="yes" shareCacheFloor="2000000" shareMoverSchedule="40 3 * * *" shareMoverLogging="yes" fuse_remember="330" fuse_directio="auto" shareAvahiEnabled="yes" shareAvahiSMBName="%h" shareAvahiSMBModel="Xserve" shareAvahiAFPName="%h-AFP" shareAvahiAFPModel="Xserve" Expecting Mover to now work again, I restarted into normal mode, as I wanted my temperature and fan plugins to keep my drives cool while the Mover got busy. On reboot, I confirmed that shareCacheEnabled="yes" was still in the share.cfg file. I then manually started Mover. This time the logged message was "root: mover: started", and I can see disk activity so it appears that Mover really is working. So it appears that my Cache drive and Mover troubles are finally over - thank you Tom and all who helped. That said, assuming Lime-Tech is already here reading this, I'd like to take a moment to recount my experiences with the -rc6/-rc7a releases: Experienced 1 Kernel Panic while in Safe Mode on -rc7a (above), and possibly another in Safe Mode on -rc6 (speculation) The upgrade from 6.3.latest to 6.4.0-rc6 coincided with whacking some cache related configuration file parameters (can't rule out plug-ins as a contributing factor) Could not assign the cache drive under -rc6, though -rc7a fixed this Several -rc7a anomalies (cache drive showing unassigned even though it was assigned, multiple Stop/Starts/Restarts required to get system synced up & behaving correctly) Currently, Mover is working but only at about 36 MB/s peak. Never paid attention before, because Mover is normally running in the middle of the night, but this seems rather slow. Possibly because data is being written to a drive that is 96% full, so this may be nothing. Odd caching in new GUI under -rc7a (didn't notice on -rc6) in which sometimes I have to Shift-F5/Forced Refresh to get current data presented. An easy example is the UPS Summary on the Dashboard, which kept reporting 157 watts for 30 minutes after I spun the drives down. I finally forced a screen refresh, and the status updated to 84 watts. Another example (plugin related) is the Dynamix System Temps ticker at the bottom of the screen doesn't seem to be updating. I've got both Firefox and IE open on the Main screen, and the ticker has been frozen on both for 10+ minutes, and they don't match each other. If I click around the menus, sometimes the ticker updates, and sometimes it just disappears. The behavior seems worse on IE than Firefox. On the plus side, the new 4.12 kernel includes some drivers that were missing, so that's pretty nice. It will take a while to determine if the C-state issue is resolved. Thanks, Paul
  10. Anybody planning a Ryzen build?

    Thanks for chiming in Tom. Yes, 7a. Okay, so I booted up in Safe Mode. With array stopped, first I check the Settings/Global Shares and see that Cache Enabled is showing 'Yes'. I don't touch anything here for the moment. I then go start the array. Whole GUI immediately becomes unresponsive, web pages returning "Server not found" errors. Telnet is unresponsive too. Can't find server by name or IP. This is the second time server has become unresponsive tonight, once on rc6, and now again on rc7a, both times in safe mode. Seems very odd that I have more problems in safe mode than in frivolous mode. There is a chance the server has hung from the C-state being re-enabled on my Ryzen, not sure at this time and don't want to rule anything out yet. One last thought: Mover worked great until I upgraded from 6.3.latest to 6.4.0-rc6, at which point it appears to have stopped working at the same time. Just thinking that might be a clue as to how the shareCacheEnabled var got whacked. That's enough for one night, gonna hit the sack.
  11. Anybody planning a Ryzen build?

    Wow, rc7 has been a rollercoaster so far... After a brief heart attack thinking the upgrade killed the server (turns out the new 4.12 kernel finally includes the drivers for my primary NIC, so I had to move my network cable), I'm now running on rc7 with C-states enabled (fingers crossed). LOL, didn't think the cache drive situation could get worse. I was wrong. Now I can't even make the cache drive assignment. I can see the drive under UNASSIGNED DEVICES, and the pretty name is back: Samsung_SSD_960_EVO_1TB_<longstringnottypingit> - 1 TB (nvme0n1) I can see the same drive listed as a selectable option for the cache drive assignment. But I've been trying to select it for 5 minutes, using 3 different browsers. I simply can't select it, it always goes back to "no drive". Seems like something got touched in rc7 related to this, since the behavior is definitely different. But different bad, not different good. Hmmm, more weirdness: Just noticed that the disk.cfg file got updated with the cacheID of my new drive, but with the array running the drive is still showing as unassigned on the Main tab, and I have no cache drive. Decided to reboot and see if that made a difference, and when I Stopped the array I noticed that now the drive is showing as the assigned cache drive. Instead of rebooting, I Started the array again, and now I have a cache drive. Tried to run Mover, and got the dreaded "root: mover: cache not enabled, exit" log entry. Stopped the array and rebooted (forgot to grab diagnostics first, sorry), and for the first time in 4 months the cache drive booted up assigned!!! Then tried Mover again, and it is still not working. Attaching diagnostics showing Mover not working. Paul
  12. unRAID OS version 6.4.0-rc6 available

    I had already tried that trick. For whatever reason, it doesn't work. And before someone asks here (since I was asked in another thread) I've tried booting into safe mode to assign the cache drive, and that doesn't work either.
  13. Anybody planning a Ryzen build?

    Yes I had tried that, but just did it again to make sure. No dice. I can open disk.cfg in Notepad++, which automatically notifies me if the file changes and asks if I want to reload it. When I start the array, the file gets touched. But not when I change the cache drive assignment. No matter what I do, the cacheId value stays the same with the old cache drive info.
  14. unRAID OS version 6.4.0-rc6 available

    Thanks, I didn't know that. Perhaps it was mentioned earlier and I just didn't see it.
  15. unRAID OS version 6.4.0-rc6 available

    I've got a problem assigning a replacement cache drive, and it appears to have gotten worse under 6.4.0-rc6. The problem started back when I was on 6.3. When I upgraded to a new Ryzen system, I replaced my Samsung 840 SSD with a Samsung 960 M.2 drive. Unfortunately, the cache assignment would not stick, reverting back to unassigned (or the old cache drive if I had it installed) on every reboot. I tried to make the assignment using Chrome, Firefox, and IE, as the FAQ indicates that this is a known problem - but nothing worked to make it permanent. At the time, I found I could simply stop the array, assign the cache drive, and restart, and everything was fine until the next reboot. Then I upgraded to 6.4.0-rc6 right when it came out, and just now noticed that Mover is broken. Here's the specific symptoms: A) As before, every time I boot up, the cache drive is unassigned (unless I install the old SSD, then the old SSD boots up assigned) B) Looking in the disk.cfg file, I see the old SSD still being referenced (cacheId="Samsung_SSD_840_EVO_1TB_S1D9NSAF627019H") C) Stopping the array, assigning the cache drive, and restarting the array appears to partially fix the problem, as now caching and VM's work. D) Under 6.4.0-rc6, the drive Identification is ugly: "eui.0025385c61b08640 - 1 TB (nvme0n1)", back on 6.3.x it seems like it was pretty, something like "Samsung 960 1TB (nvme0n1)" E) I can browse to \\TOWER\cache and see my files, and "cache" shows up in the DISK SHARES list on the Shares tab, so both of those seem good F) But Mover is broken, always logging the issue "root: cache not enabled, exit", both on manual and scheduled runs G) Looking at the backlog of files to move, Mover has not worked in a month (June 25 is oldest file) - appears to be when I upgraded from 6.3.x to 6.4.0.-rc6 I believe Mover was working on 6.3, even with the cache drive assignment issues. Diagnostics are attached. On a side note, I noticed that on Firefox the checkboxes are invisible with 6.4.0-rc6. For example, on the Main page, the checkbox for "Yes I want to do this" when stopping the array is invisible, but I can tell it is clicked because the "Stop" button becomes enabled. The same issue is on the anonymize diagnostics checkbox - impossible to tell if it is clicked. I can see the checkboxes with Chrome, Edge and IE, just not Firefox. Paul

Copyright © 2005-2017 Lime Technology, Inc. unRAIDĀ® is a registered trademark of Lime Technology, Inc.