Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

34 Good

About JesterEE

  • Rank
    Advanced Member

Recent Profile Visitors

739 profile views
  1. Upgraded from 6.8.3 without issue! Using the Nvidia drivers as well ... tested working as expected with a number of dockers and Windows Q35 VMs. Looking forward to this 5.9 kernel release!🙏 There is a patch to hwmon I've been waiting to get my hands on!
  2. That's an interesting find @keefd! Probably one of the best solutions for a modern server build where you want to incorporate some "average sized" PCI-E cards without losing space for HDD cage mounting. I do agree though, more than I'd want to spend (and that doesn't even cover the HDD cages). I've never heard of the manufacturer before ... I'd be interested in a build quality review ... So it looks like a pretty impressive case, with average or maybe a little better than average build quality. I think they priced themselves out of the market though. Fractal Design just released the Meshify 2 XL at $180 only a few months after this chassis' release. It's basically the same size and construction as the Define 7XL but it can breath instead of roast and is $20 cheaper. Even when you buy the additional trays to complete the build, you'll still be under $300 for a loaded chassis (comes with 6 trays, need 10 more for the stack [10 trays / 2 trays per package = 5 packs * $14 = $70 + $180 = $250 for 16x 3.5" drive locations and 4x 2.5" locations]). If you were set on hot swappable drives though, the Anidees AI Crystal XL PRO may be the one to beat! I personally just bought a Meshify 2 XL ... and as I build in it, I am very impressed! Still short of the 20x 3.5" drives possible with 12x 5.25" slots, but I'm happy with this case for my needs. Really still want that backplane though 😰. -JesterEE
  3. @Hoopster is right. If you had a Kepler based 730 instead of a Fermi 730, it would do some NVENC and NVDEC, but your card is a generation too old. Note the GF108 instead of GK208.
  4. Follow-up from my last post. TL;DR; APC Sucks So I got an APC RJ45 to RS232 (Serial) cable and a RS232 to USB adapter to do the firmware upgrade needed to hopefully get MODBUS over USB enabled on my UPS. Well, in APC's infinite wisdom, they apparently have different firmware ceilings for different units with the SAME SKU. Looking at the APC FAQs I found this entry on updating the firmware. So, I have a SMT1500US toaster, so I used Firmware Update Wizard 4.1.1. From the listing of firmware updates, my unit could be an SMT 4.5G with Micro-Link 17 or 18. My unit was at firmware version 5 and didn't report a Micro-Link version so I had no idea which to expect. Plugged in the cabling, launched the Wizard, and it proceeds recognize my unit and suggest an update to firmware version 7.1. HOSED! 😡 Since the thread I linked in the last post suggests that I need firmware version 9.1 to use MODBUS over USB, I'm now SOL. Who releases a 2 different products that look exactly the same without a way of deciphering which is which!? I even contacted APC support 2 weeks ago and they couldn't even tell me which I had based on my device serial number. I have to say, as an engineer myself, this is sloppy, sloppy work on APCs part and now I am very frustrated. -JesterEE
  5. FINALLY! If you have a case with lots of spinners and "thermal zones" this is the product and SUPPORT we have all been waiting for! -JesterEE
  6. Sorry to necro this post, but I was going to post a new thread about it anyway. EDIT: apcaccess result APC : 001,027,0657 DATE : 2020-07-08 12:24:13 -0400 HOSTNAME : Tower VERSION : 3.14.14 (31 May 2016) slackware UPSNAME : Tower CABLE : USB Cable DRIVER : USB UPS Driver UPSMODE : Stand Alone STARTTIME: 2020-07-08 12:23:11 -0400 MODEL : Smart-UPS 1500 STATUS : ONLINE BCHARGE : 100.0 Percent TIMELEFT : 129.0 Minutes MBATTCHG : 10 Percent MINTIMEL : 10 Minutes MAXTIME : 0 Seconds ALARMDEL : 30 Seconds BATTV : 27.0 Volts NUMXFERS : 0 TONBATT : 0 Seconds CUMONBATT: 0 Seconds XOFFBATT : N/A STATFLAG : 0x05000008 MANDATE : 2011-04-08 SERIALNO : z NOMBATTV : 24.0 Volts FIRMWARE : COM 02.1 / UPS.05.D END APC : 2020-07-08 12:24:56 -0400 Note, no LOADPCT, or NOMPOWER 😭. So, while the below is all still valid ... the issue is my UPS is not reporting what is needed for the plugin to work. Was wondering if more information was output when using MODBUS driver instead of the USB driver, but I couldn't get it to work on my unit and I see no option in the UPS physical config. Googling, I found this thread saying that I need a newer firmware to support MODBUS over USB 😭. Looks like I need to try and find a serial cable after all 😭. Sorry again for the necro when I obviously should have checked this all first. @CHBMB it looks like you were on to something. I know this was 4.5 years ago, but do you remember what was going on? Maybe it's still working for you on your current setup and you can explain what you have working. On my setup I originally plugged into a USB3 port, but after running lsusb -t, I see that even thought the port is USB3, the bus is running at USB2 speed, the device is running at USB1 speed. root@Tower:~# lsusb -t /: Bus 06.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 10000M <<<< USB3 speed /: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 480M <<<< USB2 speed |__ Port 1: Dev 4, If 0, Class=Human Interface Device, Driver=usbhid, 12M <<<< USB1 speed I tried another USB2 and USB3 port with no change in my load being reported or the bus/device speeds. Lastly, in my BIOS, USB XHCI Handoff was Enabled, so Unraid should be negotiating the USB speeds. For kicks, I Disabled that setting so BIOS has the obligation of doing this task. On reboot I get the same output from both the UPS and the lsusb -t command (which is interesting, but unrelated to this thread). So I don't think its a compatibility issue, but now I have no ideas. My APC Smart-UPS SMT1500US is on firmware version COM 02.1 / UPS.05.D. This is not the newest for this unit (UPS.07.1 is according to APC) but I can't upgrade my unit over USB ... only over a serial connection I don't have so ... ¯\_(ツ)_/¯.
  7. I mostly agree ... a ZFS RAIDZ array would be almost perfect. I like everything a ZFS has to offer and the tools that support the function. Bundle that with an Unraid style interface for common array tasks for file versioning, scrubbing, and resilvering ... 🔥! The #1 place I think ZFS still needs some more time the oven is, as @_rogue pointed out, vdev expansion. All indicators point to that being a priority for the project devs, so maybe ZFS implementation for an Unraid 7.0 release target? Soon™ One issue I see with incorporating ZFS as the "main Unraid array" is how it handles the parity in a ZFS RAIDZ1 implementation; it's just different from how Unraid does it today. While a Unraid array stores parity information on the parity disk(s), a ZFS RAIDZ stores necessary parity throughout the array. Also, the way ZFS caches reads and writes is different and can require a LOT of RAM for big arrays. I'm obviously oversimplifying here, but that fact remains, the way it works is a fundamental shift from the current Unraid state. Is this better ... or worse? I think that's subjective. However given the ZFS baked-in features such as snapshots, block checksums to protect from bitrot, and native copy on write ... I'll think I'd deal with the few downsides. -JesterEE
  8. Enhancement Request: Check for non-reduntant btrfs cache pools. I thought I was doing good making my cache redundant with a btrfs raid1 until one drive had a failure, and I couldn't mount the 2nd drive's file system. For those users that created their cache arrays in 6.7.X, this is an issue that most people are likely unaware of and would certainly cause data loss in what should be a protected event. It would be nice if this plugin would give users the heads up that something is wrong, why, and how to fix it. -JesterEE
  9. This bit me yesterday on my 6.8.3 install when a disk was unmountable on my 2 disk cache btrfs "raid1" array 😩. Just like in this post: I'm glad it's fixed in 6.8, but it would have been nice if Unraid checked for this bug and fixed it with future OS upgrades. Even a check and notification with the Fix Common Problems Plugin would have been helpful. -JesterEE
  10. This is fantastic and will make may users very happy! One question though. Currently, using the Linuxserver.io Unraid Nvidia Plugin we can pass through a GPU even with the Linux GPU driver installed. It can get a little dicey when you boot VM that tries to use a GPU that's actively being used in a docker container (Linuxserver.io even identifies this in the support thread) as it locks the Unraid OS and forces a dirty restart. Been there ... a few times 😝. But, I'd gladly take the opportunity to shoot myself in the foot rather than require that there be separate dedicated GPUs for dockers (i.e. available to Linux) and VMs (i.e. unavailable to Linux). Is there intention to retain this ability in the official release of the baked in GPU drivers? Thanks for your continued efforts @limetech! -JesterEE
  11. @Frank1940 Thank you for this work. Just as relevant in 2020 with 6.8.3 as it was in 2016 with 6.2.
  12. Maybe in the future. All the updates and support are great! Thank you! My Dashboard docker alignment still gets a little skewed using Docker Folder. I know you did some work with it, but on my dashboard, the folder contents shift to the right when the Started Only setting is selected. I think it doesn't recompute the docker folder splitting based on that option.
  13. I disabled all my plugins and restarted. Then I enabled one plugin at a time and restarted till it popped up. As soon as I turned on the VM Backup plugin it started happening. I disabled all the other plugins and restarted (keeping the VM Backup plugin enabled) and restarted. Still there. Check with the VM Backup plugin support thread to see if there is any info on an update there. If not, no, there is no "repair" and a reinstall won't help.
  14. Quick note about this kernel build with regards to the fix for onboard audio passthrough on x570. I have been tracking the Linux kernel git source to see if this issue has been addressed on the trunk, but unfortunately, it has not. There is also the possibility that AMD would address this issue in firmware with an updated AGESA ... but the sparsely documented notes for the latest to-be-released AGESA firmware say nothing about the on-board audio. So the if we have any hope of using the on-board audio on our boards in Unraid, a patched Unraid kernel with this patch will be required. Luckily, we have a Skitals! As a user of the NVIDIA Unraid build, I'm going to be forced to choose between my GPU in docker and my audio in my VM, which is unfortunate. It looks like I'm in the market for a USB audio DAC. 😒 EDIT: Looks like some people asked AMD to comment about the USB and audio with the AGESA, and others actually tried it ... no dice!
  15. Enhancement Request: Can a monitor be added for the PCI Rx and Tx bus speeds reported in the nvidia-smi -q -x command? Is has been reported in the logs here as: <nvidia_smi_log> <gpu id="00000000:0A:00.0"> <pci> <tx_util>320000 KB/s</tx_util> <rx_util>3686000 KB/s</rx_util> </pci> </gpu> </nvidia_smi_log> Thanks! -JesterEE