Leaderboard

DVA1622 AI works on VM After I had successfully make AI working on the baremetal NUC 6 Skill Canyon, I am now able to make it working on ESXi 6.7 on the Quartz Canyon nuc9vxqnx w/ GPU passthough for Intel UHD 630. I guess it's due to a Pro version of NUC with Xeon processor that supports with Vt-D. My next step would be passthough a Quadro P2000 for DVA3221 in VM on the same ESXi box as soon as it arrives.

Hi, Just managed to get a 7.1.0 VM up and running (finally) and thought I'd give my 2 cents for the issue I had and how I worked around it. (Can't find this error in the posts here but I'm bad at searching. :)) Using a vcenter7/ESI home lab, I tried to follow the instructions but I got stuck on the SATA part and VM wouldn't start: "Unsupported or invalid disk type 2 for 'sata0:0'. Ensure that the disk has been imported. Failed to start the virtual machine. Module DevicePowerOn power on failed. Unable to create virtual SCSI device for sata0:0" I tried using IDE instead of SATA (which I found as a common workaround when you get this error message above) but that ofc didn't work. Got stuck at 55% on the DSM install. (possible file corruption) In the end the workaround for me was just to do a simple clone of the VM at the point where in your instructions it's ready for "step 3", that is, when VM is ready for powerup, disks already added and so on, and then use the clone instead of the original VM. (Unclear to me if this was a fluke or if it indeed changes something in the VMDK structure when cloning.) Anyway, my 2 cents. /Mike

If you are referring to me since you were not specific...I think if you read what the problem I encountered actually revealed some minor issues with TCRP to which Peter and Poco have solved and still investigating at the time of this post. If this occurred with me then it can easily happen to others and having this info reduces the future post and most importantly "stress" new or upgrading members might encounter. The mods here are very capable to sort the info. TCRP and Friend are really awesome pieces of tech and it seems they are fine tuning this thing to be that much better. Please remember, not everyone starts as an advanced/expert user. The info shared with me from other senior members here has allowed me to help other new users. My account is new but I am not new to this forum. Happy New Year Everyone!!!

Sorry to keep you all waiting, I was away from the computer for a few days. I have done a lot of test on this in the last few weeks, pretty sure I know what is going on. Let me try to explain what is happening... The issue The simple answer is that the system is stuck in either a low performance mode (to save energy), this is the case with ARPL. The opposite is true for TCRP, in which it is stuck in a higher frequency mode. The core of the issue lies in an add-on called misc. This add-on performs a couple of checks about the CPU the disable certain kernel features, to prevent a crash if not available. One of them is checking for the ability of the CPU to perform performance scaling. In other words it's checking for what Intel calls SpeedStep, don't know what the AMD calls this feature. The performed check doesn't work like intended and is flawed in my opinion. It checks for features in a device directory, which don't exist at that point yet. The result of this is that the kernel module called acpi-cpufreq is not loaded. Once loaded the directory is populated. This issue was previously reported, I guess the consequence wasn't realised. This acpi-cpufreq module manages performance scaling with a governor, there is more than 1 but the default governor on the models I've tested is called performance. When there is no load the governor scales the CPU down to save energy, and scales up again when there is a need for it. All models that include the misc add-on are effected by this missing module, even the 3615xs. Although it loads the acpi-cpufreq through another kernel module called mperf, this results in a normal experience. It might be possible that different models use different governors, but once the real issue is fixed it loads the preferred governor anyway. Loader differences Why is there a difference between the loaders? I'm not 100% sure about this, but I have a very plausible idea. Since the DSM system, doesn't start by itself on anything but Synology's hardware, we need a loader to perform a couple of steps, before it turns over to DSM. These loaders, ARPL, TCRP or Jun are by them selfs systems with its own kernel. This means the loader manages this performance scaling and then turns it over to DSM. The difference in performance between ARPL and TCRP might be the result of this. The ARPL loader sets the performance scaling into the userspace governor, with the minimum frequency, once in DSM and unable to scale it up because of the missing kernel module, the result is the low performance. I've force ARPL into a higher frequency and loaded DSM and the result was the higher stuck frequency in DSM. TCRP starts with a different governor and seems ok, but also has the missing kernel and the result is it doesn't scale down. When using TCRP withfriend it has the same low performance as ARPL, which proves this even more. On a real Synology or even perfectly working XPEnology NAS it might seem it not scaling, but it definitely is. You just need to look in the right place. Fixing the issue It's not very hard to fix this issue. There a several ways of doing this, the best way is to put in place better checks in the misc add-on so everyone benefits. I have a couple of ideas for this but I need @pocopico and @fbelavenuto to give me a better idea why it was implemented. Right now I think it's really just needed on hypervisors, where I replicated the issue with a crash. Since the host of the VM manages the CPU, there is no performance scaling inside the VM and all modern CPUs should be able to do so when running bare metal. Temporary fix Right now I would suggest to go with a temporary fix (for advanced users only), which needs to be re-applied once restarted. This has the benefits of getting things up again, might there be a crash on your system, which this check in misc is trying to prevent. This needs to be run in the shell as root, if you don't know how to do this, I don't think this is for you right now. I have done my testing on an isolated drive, with ARPL but TCRP should work too. If you do this make sure you have an idea what you are doing, there is always a risk of losing data if something goes wrong. modprobe acpi-cpufreq && echo "performance" | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor The modprobe loads the kernel module and on success it forces all the governor into performance mode. Once loaded you can check if you get an output. grep . /sys/devices/system/cpu/cpu0/cpufreq/* Hope you guys find this helpful, and appreciate the work I have done. Aswell as what the people working on these loaders do, mistakes happen, please don't blame anyone.