bungee91

Members
  • Posts

    744
  • Joined

  • Last visited

Everything posted by bungee91

  1. Normal behavior, mine is the same and works perfectly icon for kill switch is set default config file(s) appear to be in place .Xauthority file appears to in place kill switch is set setup desktop icon is set mythtv folders appear to be set Database(s) exists. Starting MariaDB... Checking whether database(s) are ready waiting..... waiting..... icon for kill switch is set default config file(s) appear to be in place .Xauthority file appears to in place kill switch is set setup desktop icon is set mythtv folders appear to be set Database(s) exists. Starting MariaDB... Checking whether database(s) are ready waiting..... waiting..... waiting..... icon for kill switch is set default config file(s) appear to be in place .Xauthority file appears to in place kill switch is set setup desktop icon is set mythtv folders appear to be set Database(s) exists. Starting MariaDB... Checking whether database(s) are ready waiting..... waiting..... icon for kill switch is set default config file(s) appear to be in place .Xauthority file appears to in place kill switch is set setup desktop icon is set mythtv folders appear to be set Database(s) exists. Starting MariaDB... Checking whether database(s) are ready waiting..... waiting..... icon for kill switch is set default config file(s) appear to be in place .Xauthority file appears to in place kill switch is set setup desktop icon is set mythtv folders appear to be set Database(s) exists. Starting MariaDB... Checking whether database(s) are ready waiting..... waiting.....
  2. I'm eyeing a Corsair HXi or AXi PSU, may not tell the wife and see what happens.
  3. When running these checks (never had to) can I do it with the array active, or need to be in maintenance mode? (No comment on the unfortunate circumstances for his wife.. It also hard to make it laughable in any way (I did try, seemed wrong) ) Does anyone know of a CPU utility to properly test for defective conditions? Kind of like a hard drive long test, S.M.A.R.T. check? Considering all the I/O it does, Vt-D, various extensions, memory controllers, it's hard to know for sure if something is just a little off. A dying MB that was left on with a clicking supply (likely its own internal protection) can't be good for a couple million transistors..
  4. Edit: Needed to look further. You should be able to get the 00:14.0 USB controller: Intel Corporation Sunrise Point-H USB 3.0 xHCI Controller (rev 31) or the 03:00.0 USB controller: VIA Technologies, Inc. Device 3483 (rev ff) controller. Is this the ones you're trying? The add-on card and sound card still apply to what I'm talking about below. Without the ACS patch working for Skylake builds (one user says it does work for him, but he's unfortunately not the majority of cases I've read) considering the grouping, there is NO way this is going to work.. (not trying to be mean) . The issue is that what you want to pass is all in group 7, all this stuff: /sys/kernel/iommu_groups/7/devices/0000:00:1c.0 /sys/kernel/iommu_groups/7/devices/0000:00:1c.2 /sys/kernel/iommu_groups/7/devices/0000:00:1c.4 /sys/kernel/iommu_groups/7/devices/0000:00:1c.6 /sys/kernel/iommu_groups/7/devices/0000:04:00.0 /sys/kernel/iommu_groups/7/devices/0000:05:00.0 /sys/kernel/iommu_groups/7/devices/0000:06:01.0 /sys/kernel/iommu_groups/7/devices/0000:06:02.0 /sys/kernel/iommu_groups/7/devices/0000:06:03.0 /sys/kernel/iommu_groups/7/devices/0000:06:04.0 /sys/kernel/iommu_groups/7/devices/0000:06:05.0 /sys/kernel/iommu_groups/7/devices/0000:06:06.0 /sys/kernel/iommu_groups/7/devices/0000:06:07.0 /sys/kernel/iommu_groups/7/devices/0000:07:00.0 /sys/kernel/iommu_groups/7/devices/0000:08:00.0 /sys/kernel/iommu_groups/7/devices/0000:09:00.0 /sys/kernel/iommu_groups/7/devices/0000:0c:00.0 /sys/kernel/iommu_groups/7/devices/0000:0e:00.0 /sys/kernel/iommu_groups/7/devices/0000:0f:00.0 That's a LOT of stuff unfortunately, and to properly pass hardware (anyway you get it; naturally, ACS override) you need to pass everything to each VM, or stub it (not use it). This doesn't apply to root ports in the grouping. Your sound card that failed was also in the same group (9) with your ethernet card, which I assume you don't want to pass as you need it for UnRAID.
  5. No hating on X99 , we have proper ACS and no IOMMU grouping issues (I think your thinking Skylake and Z/H170 chipset). The thread you're mentioning for the rom, etc. is here (I have not attempted this) http://lime-technology.com/forum/index.php?topic=43644.msg452464#msg452464
  6. Thanks! I appreciate the input and thoughts with this. Being that I had some pretty nasty failures, to me everything is suspect. I cannot think of anything else that would be more likely than the CPU for the TSC clock sync error, and that it at times freezes at that one point (maybe this new MB I am using temporarily is partially defective, it would be unlikely, but at this point I don't know). I have completed parity syncs after both hardware failures/lockups without any issues, while still having all other VM's, etc. operating. This is why I don't feel the PSU is the culprit. I ran Memtest over night (~8 hours) completed 3 passes without any issues (this is with XMP set to off). Here's my current plan as I see it. Wait for my MB to come back from RMA, set it all back up and see if the problem exists. Run Memtest for a couple of passes with "Profile 1" XMP set to on and verify no issues (this should work as it always did previously). At that point I'll make a decision as to if I want to replace the PSU (or test with a smaller unit I have), or RMA the CPU. I have since scrubbed my Cache drive and found no errors present. I'd like to run a verification on my array XFS discs for any corruption. What would be the best way to accomplish this? Parity sync finished both times without errors.
  7. So........... It's been a "slice" lately in the world of my server.. The short and skinny (read bold): About a week ago one of my rear USB ports no longer worked at all, just all of a sudden dead. Back story:This was being used by my UPS, so I got a notification it went offline. Checked cables, reseated, no dice. Plugged into another open USB port, all is well. A week later my server is unresponsive, frozen, all VM's, etc... offline. Server was on (fans spinning) when the wife originally let me know. Hours pass, I get home. NIC LED's are flashing, but the computer is now powered off. Turns out my primary GPU is dead, DEAD... No response, MB hates when it's installed (acts odd, won't boot, no POST beeps). Test in another computer, it won't display and I get a POST beep (likely) indicating no video. Buy a new primary GPU, all is well, back in business. A couple of days later. My motherboard died, DEAD, and needed to be RMA'd. Back story: I came home to a server off, with no NIC lights, and a power supply making a soft tick, tick, tick noise. Did all the testing one would do (swap power supplies (same tick), eliminate extra components), it was dead. I purchase the exact make/model motherboard and replace it (Gigabyte X99-SLI) to ensure it is not something else, and it boots right up, on and working (or so I thought). Hindsight (20/20 = a lot of broken shit! ) Now thinking about this all, the dead USB port, the dead video card, and the now dead motherboard I realize it's all related, and the MB while slowly dying was taking things out with it.. So anyway the new MB had some quirks when changing BIOS settings, as it wouldn't save some time, or would cycle on/off as if it couldn't boot up/POST properly (far more than normal). At times this would lead to the settings being set to default. At first I hadn't loaded the newest BIOS (which the original one was super old), so I updated that to the newest (same as my previous MB that worked fine prior to its demise). This really didn't fix anything, similar situation. I finally found the reason for what seemed to be a lack of proper power up/resetting of settings, and that was the "Profile 1" being set for the XMP memory settings. If I leave it set to off/disabled the settings retain as they should, and the power on/off at boot is better (but still not what I recall as normal for this board). My original motherboard (identical in every way) always had the XMP profile 1 set, and I had previously ran Memtest for 24+ hours verifying it was working properly. I also used this for the last ~3 months without any of the issues I'm describing to you. Anyhow, whatever, boot into UnRAID and sometimes it gets stuck loading at the attached screenshot screen. I let it sit there for a good 5 minutes, and it is stuck. Reboot server (button press) and it will likely load up the next time. Continue on, but have an error in the syslog about the clock or HPET being off, and it complaining (all settings in BIOS are correct, time is correct, not sure the exact message). I then start to get a couple of these over a short period of time: Mar 29 05:20:52 Server kernel: pcieport 0000:00:03.0: AER: Corrected error received: id=0018 Mar 29 05:20:52 Server kernel: pcieport 0000:00:03.0: PCIe Bus Error: severity=Corrected, type=Data Link Layer, id=0018(Transmitter ID) Mar 29 05:20:52 Server kernel: pcieport 0000:00:03.0: device [8086:2f08] error status/mask=00001000/00002000 Mar 29 05:20:52 Server kernel: pcieport 0000:00:03.0: [12] Replay Timer Timeout Never seen those before... I research the issue, it seems to be mentioned in some bug reports from as far back as 2011, nothing current, and not something you'd expect. So I figure out which GPU it is, swap it out (same model), and the error is much less frequent, but I still see it once in a while (thought that GPU may have been bad as it was in the next slot next to the one I had to RMA, but I don't think that's the case). So... As of now I am typing in a VM right now (primary computer), have 3 others going (2 of those with GPU's). My server is "working" but it seems flakey at best. No stability issues to report, I've even hammered two of the VM's with multiple performance tests to stress them. I have a Corsair TX650W that has served me well, and I really don't think it is bad in any way. However it's one of my next things to look into further. Now my question: Do you think it is possible my CPU was damaged "lightly" when the MB, or video card died? I have never seen this model MB lose settings, not be able to set the XMP profile to 1 (on), or power on/off at boot until it finally goes. I think (even though it is unlikely) that the MB died from far too much concrete dust that built up a bit in my server when I was removing some of a concrete floor in my basement (yes I'm an idiot, should have been more careful). A link to a diagnostics from the other day (with the PCIerror in syslog), and one from just now. https://app.box.com/s/r1kg2zr4jud3vkiclq0f7go36q5g4erc ---- Also: Yes I know about all the USB related "rounding interval to" and "reset low-speed USB" messages in the syslog. They've been there forever, and only changed as I attempted to disable the XHCI controller, leading to it now listing the "reset low-speed" message, instead of the rounding one.. May need some powered hubs/better USB extensions.
  8. And that was with Seabios or OVMF? (You didn't ask me, but I'm here reading) This only worked with SeaBIOS, not OVMF, as I get the boot loader options, and no booted Kodi Installer menu. On another note: I still don't get why SeaBIOS doesn't work for you!?.. I have 2 different makes/brands of the GT720, and they all work with it.
  9. Ok, will try this again soon. I started with 10GB vdisk, 2GB ram, and 2 cores, so we're good there. Did you have issues using Q35, or did you just choose 440fx? I ask as I did, and if I recall, the "recommended" chipset/emulation for Linux is Q35 which my keyboard (weird) doesn't work in. As to this "Again the OpenGL error occurs on first boot while still in VNC mode" that's the thing, it happens when installing this with the GT720 passed through also.. I did the install as I was planning on using it (no VNC, just GT720).. I couldn't (easily) figure out my IP for using SSH, but at that point I didn't know about the Ctrl+Alt+F1 option, and thought I couldn't input anything. So this is why it wasn't very straight forward. Anyhow, I'll check out the video soon. Thanks.
  10. Interesting, thanks for the info! It was “creative differences” and rock-band analogies that broke them apart... I like OE, but I have a shared library and am impatient and hate waiting (certainly don't have to wait for the update on my Windows machines!). ------- Anyhow I just recently tried to get this going (Kodibuntu), and it was just as bad as I remember prior to sticking with a full blown (and waste of space/resources) Windows install. So some input and help on my path would be appreciated. 1st off, I have a GT720 I'm using with this, so we're on the same page there. Only SeaBIOS works, no OVMF (as mentioned it doesn't boot the installer in this mode), however that's fine by me. If I use Q35 (newest) instead of i440FX (newest) my keyboard I have attached for install doesn't work at all, works fine under 440fx, and my basic Windows remote receiver doesn't seem to work regardless (may not be "eHome", but could tinker with at another point). Regardless if I install with VNC or using the GT720, I always get the "No OpenGL hardware ...." error message. You recommendation seems to fix this, and get Kodi to boot: add the graphics-drivers ppa: $ sudo add-apt-repository ppa:graphics-drivers/ppa $ sudo apt-get update install the latest driver (use the major release number) $ sudo apt-get install nvidia-361 restart your system $ sudo reboot Then I want to update to Jarvis, so I put in the following: sudo apt-get update sudo apt-get upgrade It seems to update a LOT, but says it skips a couple from updates, the two I noticed were Kodi and nVidia something... I then told it to update kodi (whatever it is, apt-get update kodi, or something of that nature). Completed, reboot, black screen... Ctrl+Alt+F1 (never knew this little trick existed!!), I get an error that Kodi can't load, something something... Sudo reboot, Kodi loads!!! However no sound, and (my order may be a bit off) I have a very often re-occuring message in Ctrl+Alt+F1 (console) for intel-hda error (or something) continuing..... Kodi is at version 16.0 (not 16.1RC), not sure if the RC isn't available, or my install just hates me. I figure this needs the same MSI trick to fix (as mentioned here), so I go looking for it's location, and FTP into KodiBuntu. I have the .config, but no path for modprobe.d or the sound.conf file within it. So I create them in the same location (is it different for Ubuntu?), sudo reboot (from SSH). I'm not sure if that did anything, but I'm no longer at the console (Ctrl+Alt+F1), and am in Kodi, however I get NO sound output. I try all 3 options under the System audio section (default HDMI, something else HDMI, and HDMI Toshiba TV), and none of them output any sound. This is the point I gave up for the night, so I may waste another couple of hours soon but would be very grateful for some input/knowledge from the OP or others that have gone through this.. I think it is retarded that the KodiBuntu image (even though Ubuntu has a 5 year support cycle) isn't updated, and requires an old Helix install as a base to get this going! Plus then like 300 updates when running the sudo apt-get update command.
  11. (thinking about fiber currently) Ok, maybe I thought about this incorrectly then. The point here is to (hopefully) catch some good diagnostic information prior to a lockup, and then be able to use that after the hard reset is performed (as it would have been lost normally), right? So were hoping whatever is going on is logged prior to it getting to the point of failure. For some reason I thought cron was still operating some way, and that even though we are locked up from accessing/controlling UnRAID, that if we waited, the cron job would happen and capture all the relevant information. I guess that's not the case, so disregard.
  12. My question would be, is there a way to invoke this prior to doing a hard shutdown? I understand the powerdown script collects information when used, but this use case is for when we cannot do that. Could we monitor the power button input, for say a double press, which would invoke this?.. Just thinking out loud for a way to trigger it when the system is up, but any normal way to control it has stopped working.
  13. What PCIe slot is the Nvidia GTX 760 (Asus) in? If the 1st 16X slot, try moving it to another one. Also, what GPU is the BIOS set to be the primary GPU?
  14. Performance wise, there should be no difference, other than people with specific issues that are fixed by using UEFI/OVMF. SeaBIOS is apparently quite the hackery for VGA arbitration, and (as you may be aware) breaks the console output once you start a VM using it. Here's a quote from Alex Williamson of Redhat/VFIO ""The VGA space itself is a shared resource, so every time the guest tries to access VGA space it gets gets trapped into QEMU, which forwards the request to VFIO, which negotiates with the VGA arbiter and adjusts chipset routing as necessary. Therefore VGA mode is bearable when there's one consumer, once you start getting contention and the arbiter needs to switch routing on each access, this can certainly become a bottleneck. However, even when using a legacy BIOS with x-vga, those VGA accesses *only* occur during early boot or if you're using non-accelerated drivers, so the window for contention is very small. Once the guest is up and running, access to legacy VGA space ceases, and there's no performance difference between legacy BIOS and UEFI that I'm aware of." https://www.redhat.com/archives/vfio-users/2016-February/msg00036.html So UEFI is certainly the "way forward" and allows you to initiate a GPU after the initial POST, etc. My recommendation is this: If you're setting up a new VM, choose OVMF/UEFI. We initially had the issue of not being able to have more than 1 OVMF VM, so I stuck with SeaBIOS, but that is fixed now. If you already have working VM's (I have 4 this way) and the downside of this doesn't bother you (losing console, maybe also the new GUI boot mode), leave them alone and continue to use as is. There is a way to switch a Windows VM to UEFI, but it doesn't look to be very straight forward (from what I've read), and is likely easier to just reinstall.
  15. Simple answer is yes. (While I have not upgraded yet, and will wait for you poor suckers to do the testing.. (kidding, calm) ) If you disable ACS and stub all the other devices in that group (and NOT use them), then you don't need it. However this has nothing to do with the natural grouping of devices, more for UnRAID to assign the devices that are then stubbed, and "free" to assign. The basics for IOMMU grouping are the same in that: a) you either pass all devices in the group to one system b)stub the devices you don't use and don't use them at all. The ACS patch will break them up, where the a/b above will not be an issue.
  16. Since you asked this, did you follow the directions from here when doing the install (the order supposedly matters, but I doubt the order would cause your issues!)? http://lime-technology.com/wiki/index.php/UnRAID_Manual_6#Installing_a_Windows_VM I loaded only viostor driver on install and then installed the rest when windows was installed, i used version 112. You should fix this, go into the device manager and install what is likely missing. As for MSI interrupt, use this utility, run as administrator, select the GPU and audio device, save, close, reboot. http://www.mediafire.com/download/hr...i/MSI_util.zip (if the link doesn't work I'll send it to you once I'm home). Edit: Attached to my post here https://lime-technology.com/forum/index.php?topic=46264.msg442915#msg442915 You can also do this the manual, long, pain in the ass way here http://lime-technology.com/wiki/index.php/UnRAID_6/VM_Guest_Support Towards the bottom in the section Enable MSI for Interrupts to Fix HDMI Audio Support
  17. I don't know your hardware, but you can try to add iommu=pt in your syslinux.cfg file, and also vfio_iommu_type1.allow_unsafe_interrupts=1 (I don't think the order matters). It would look like this: kernel /bzimage append iommu=pt vfio_iommu_type1.allow_unsafe_interrupts=1 initrd=/bzroot Try one, or both, and see if it helps.
  18. Since you asked this, did you follow the directions from here when doing the install (the order supposedly matters, but I doubt the order would cause your issues!)? http://lime-technology.com/wiki/index.php/UnRAID_Manual_6#Installing_a_Windows_VM
  19. The effort to switch from SEABios to OVMF/UEFI isn't worth it, unless you want console output (as the console dies when you start a VM with SEABios). This may change with 6.2 with the supposed UnRAID GUI on the host, but, we will wait and see what that is all about. "The VGA space itself is a shared resource, so every time the guest tries to access VGA space it gets gets trapped into QEMU, which forwards the request to VFIO, which negotiates with the VGA arbiter and adjusts chipset routing as necessary. Therefore VGA mode is bearable when there's one consumer, once you start getting contention and the arbiter needs to switch routing on each access, this can certainly become a bottleneck. However, even when using a legacy BIOS with x-vga, those VGA accesses *only* occur during early boot or if you're using non-accelerated drivers, so the window for contention is very small. Once the guest is up and running, access to legacy VGA space ceases, and there's no performance difference between legacy BIOS and UEFI that I'm aware of." https://www.redhat.com/archives/vfio-users/2016-February/msg00036.html As for Virtio, these are the drivers you install for network, storage controller, balloon (ram), and serial. If it was HDD related, I'd recommend updating the storage controller one. Have you ran any HDD benchmark's like Crystal, or similar? I DO think it's CPU related, but, I was surprised to see the results I did with latency when doing that test. You can update the ones with the red arrow by the normal way you update Windows drivers, just pick the version of Virtio you plan to test from the fedora site (don't have link at moment, the VM add page links to it).
  20. I decided to leave the latency monitor app open while running some tests with PassMark Performance Test. Most of the tests didn't generate a lot of spikes (2D, CPU, Memory), however the All option under Disk made the bars consistently as high as possible until completed (see pic of red bars spiked for a period of time). Have you tried other Virtio drivers? I know there have been complaints with the newest versions on the VFIO group, but not certain the exact issues.
  21. I decided to see what the latency checker says for me, even though I don't feel lag/etc... I moved the windows I had open around, pinned to the left, right. Anyhow, almost every time I did it, I got a bad red spike However it never felt felt anything other than as expected, bare metal, etc... My mouse doesn't jerk, jump, nada. Now you have a real issue with a game, and that is certainly not normal, however I think the latency checker results at times can be taken with a grain of salt. I do GPU accelerated playback regularly without issue, and 1080P YouTube play without any issues either. I don't have a 4k output like you however. Didn't expect the result to look this bad.
  22. This is not your issue. All devices in group 1 must be passed to the VM, or "stubbed" to not be used. Under the system devices you can find out your IOMMU grouping for your hardware. http://lime-technology.com/wiki/index.php/UnRAID_6/VM_Management Specifically
  23. However, unRAID does only seem to use the first nr that is entered after the = mark, so in this example unraid only used core nr 4 and not the inteded 4 and 5. And when i click edit on my VM after i have enabled this using the xml edit only core 4 is checked. Is there any other way i can make it so my VM uses 2 real cores per virtual core? While I have done some manual manipulation of the XML's for UnRAID, I have not played with the vcpu - logical assignments directly. So if you edit the XML manually, and change the setting from 1 - 1 (vcpu to logical) to be 1 - 2, and save, when you go to edit XML again, does your input persist? I would think it should. You can also use the <emulatorpin cpuset => entry for core assignment to force the emulator (440FX) to run on a specific core, and not interfere with interrupts from the host (UnRAID). You can assign it to the same cores as the VM, or an alternate core just for its usage. You'll have to play/experiment as needed, but should help if latency is the main issue. You'll find this discussion here https://www.redhat.com/archives/vfio-users/2015-September/msg00041.html
  24. Unfortunately at this point I'm out of solutions to help (sorry, but didn't want to leave you hanging here). The other issue is that the amount of people doing this with AMD hardware is lower in comparison to Intel, so that gives less input from users who may have a similar situation and can provide solutions. There are certain things you can attempt to add to your syslinux.cfg file that may be of help to isolate this (not just isolcpus), but I don't have the specific answer to that. If you're adventurous, or determined, I'd highly recommend asking your question in the VFIO mailing list, as there are some incredibly bright people there who will likely give more input than I can that may help. While this is not specific to UnRAID, it is specific to VFIO/QEMU/KVM and will likely get you a quicker response than here. Anyhow the information is below: Sign up https://www.redhat.com/mailman/listinfo/vfio-users Archived threads (a lot of good information in here) https://www.redhat.com/archives/vfio-users/ Hope you get it resolved soon!
  25. If the device(s) that you want to pass to a VM are within their own IOMMU group (or all of the ones you want to pass are in the same group), you shouldn't have an issue. The issue is if the device(s) you want to use in a VM are grouped with other devices, as it is an all or nothing kind of thing for it to work. If you do not have this issue, then you should be fine (there is no great way to know other than testing, or asking someone with the same hardware you're considering). If you do have this issue, apparently the patch for ACS override does not work with Skylake at this time (however another user said it does work for him, but I'm uncertain of those details), but keep in mind this isn't "recommended" but likely a fine alternative for those who need this option. If you already have a Skylake build, I would think that you shouldn't have much issue (without seeing grouping, I am guessing a bit) getting a single VM with pass through going, and other headless VM's up to as many as reasonable given ram/CPU concerns. The V3 Xeon does not support ACS on root ports, which is what ACS is all about. However, again, for 1 VM with pass through, your grouping of IOMMU groups may work out well with little to no issues (this is hit or miss with MB/CPU's, this is the same situation for Skylake or v3 Xeon) The V5 has ACS on root ports, plus other bells and whistles. I think the bigger question to ask yourself if you're looking at Xeon's, is the addition of ECC memory. Certainly something that is better to have than not, but again, what kind of $$ do you plan to spend on this? If you don't want ECC memory (not getting into this debate, however again it is certainly better to have than not), but want ACS on root ports, I'd recommend the "old" Haswell i7 "Extreme" processors which have ACS capabilities. You really can't go wrong with the E5 other than price.