Jump to content

1812

Members
  • Content Count

    2339
  • Joined

  • Last visited

  • Days Won

    11

Everything posted by 1812

  1. there are more hp tips/tricks in my sig
  2. post your full diagnostics tools>diagnostics first guesses are that you either didn't replace the bzimage correctly or you didn't reboot after replacing the bzimage...
  3. exactly. I have a main server and a backup server, each running a firewall vm. easy to change over if the main goes down. I had issues getting sophos auto-failover working when I messed with it a few months ago but hopefully I'll get it setup soon and have automatic backup going, whether that way or in tandem with a mini pc.
  4. I use to think that way, until I didn't.
  5. Have run pfsense a bunch, also opnsense for a bit. ive been on Sophos utm 9 for about 6 months or so and really like it. Going to setup failover on a small fanless pc in a month or two that will take over automatically if the virtualized firewall goes down
  6. in the link below, follow the steps for passthrough (most likely need to allow unsafe interrupts". I have a z400 right next to me at this moment running 3 vm's all with GPU passthrough, so it is possible... though the 560 may not work due to being older.
  7. there are quite a few reasons that can happen and without diagnostics, it would just be wild guesses.
  8. something may have gone awry during the vm creation process. either force stop/start and see if it fixes itself. if not, recreate the vm.
  9. then my work here is done.
  10. a few things: Jul 26 16:06:32 unraidNAS kernel: ACPI Error: SMBus/IPMI/GenericSerialBus write requires Buffer of length 66, found length 32 (20180810/exfield-393) Jul 26 16:06:32 unraidNAS kernel: ACPI Error: Method parse/execution failed \_SB.PMI0._PMM, AE_AML_BUFFER_LIMIT (20180810/psparse-516) Jul 26 16:06:32 unraidNAS kernel: ACPI Error: AE_AML_BUFFER_LIMIT, Evaluating _PMM (20180810/power_meter-338) Jul 26 16:06:40 unraidNAS ntpd[1898]: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized Jul 26 16:06:51 unraidNAS kernel: ACPI Error: SMBus/IPMI/GenericSerialBus write requires Buffer of length 66, found length 32 (20180810/exfield-393) Jul 26 16:06:51 unraidNAS kernel: ACPI Error: Method parse/execution failed \_SB.PMI0._PMM, AE_AML_BUFFER_LIMIT (20180810/psparse-516) Jul 26 16:06:51 unraidNAS kernel: ACPI Error: AE_AML_BUFFER_LIMIT, Evaluating _PMM (20180810/power_meter-338) you can fix that via the directions in the thread I posted earlier. Jul 26 16:08:58 unraidNAS kernel: NMI: PCI system error (SERR) for reason a1 on CPU 0. Jul 26 16:08:58 unraidNAS kernel: Dazed and confused, but trying to continue I've gotten these randomly on proliants. Sometimes its hardware config, sometimes its bios setting being wonky. I'd recommend downloading the latest available from HP (they made one for all the spectre issues) It may fix that. for your gpu, try recreating the windows 10 vm with seabios
  11. Save yourself time and aggravation and just buy an hba card. H220 or Lsi variant will work great and you'll be done. Sent from my iPad using Tapatalk
  12. Try to start the vm and immediately after all fails post the zip file from tools>diagnostics Sent from my iPad using Tapatalk
  13. You never listed your plex needs so kind of hard to answer. Few days ago I setup a low powered ml30 g9 and a gt 710 using lsio docker and nvidia unraid. Its fast and fantastic. If you don't need a ton of transcodes at once, don't waste your money on an overkill gpu. Sent from my iPad using Tapatalk
  14. in regards to the 6870 not passing through, it may be too old or just have general AMD passthrough issues.
  15. No worries. Part personal experience, part understanding of what plex does. When plex starts to use /tmp as a transcode directory, it either it doesn't seem aware of the size it can write into or uses the total size of ram as its "available space" regardless of system utilization. So, it fills until it can no longer fill anymore. If you fill /tmp with plex transcode data, which the system also uses but can't directly manage or flush because plex is in control of the transcode files, then the system no longer has the ability to use /tmp, causing system lockups. And it seems like when this happens, plex still tries to continuously use the /tmp even as the system is working to purge cached files to maintain operational status as it sees /tmp filling. Eventually the system is left with only its initially occupied ram space and no free space to operate in, causing hangs in operations. At the same time, the plex transcode crashes and in doing so, leaves the transcode files in place (vs removing when you exit a transcode stream), most likely due to plex not having enough ram itself to execute the procedure (because, it's full of transcoded files.) The last time I tested and experienced this was about 6 months ago. When you specify the a folder of fixed size, one of two things happens: 1. plex writes until it is full, stops the transcode, and then every stream thereafter has functional garbage collection of the oldest transcode streams utilizing the space up to the size of the folder or 2. plex is aware of the size of the folder before it reaches capacity and executes functional garbage collection of the oldest transcode streams up to the size of the folder. I once had a server with 64GB of ram and had no issues transcoding to /tmp. But when I moved my plex docker to a more power efficient server with only 8gb of ram, this was a continual issue transcoding to /tmp. I could watch df -h and see it happening in realtime. I then move to a 1tb ssd for about 4 months without issue. I then discovered the ability to make a specified plex "scratch disk". This reduced wear/usage on the ssd (which was also doing other jobs) and I was able to have steady, smooth streams with plex.
  16. popping in to say thanks for this script. using it without out any observable issue currently
  17. Just a quick stop in to say THANKS to LSIO folks and @CHBMB for this. I installed it last night and used an old 1GB gt 710 with plex. Seems to be working without issue even though Nvidia-smi: Never shows a process (but it is working because the reported temp changes on the gpu and cpu load is less Power used doesn't ever change from N/A seems stuck at P0 but it's a 19 watt card, so, I guess thats ok Using this old cheap card GPU took my ml30 get 9 from pegging 3 threads at 100% for about 2 minutes to transcode while creating a buffer to about 50 seconds of pegging 2 threads to transcode while creating a buffer. For fun I added the nvdec script and now a single thread never pushes above 25%, there is essentially no buffer lag meaning near instantaneous playback of transcodes, and it only uses about 200MB of the cards onboard ram. If you're using this in a home environment with only 1-2 transcodes anticipated, I don't see why you would need anything more powerful. It's a very economical and effective implementation of hw transcoding in plex.
  18. Because plex can fill /temp, using all system memory, causing system hangs, stalls, and lock ups.
  19. It’s better to do it at the first array start before the docker starts, otherwise the path is invalid. If you’re just trying it out, shut down plex, make the directory with the script, edit plex settings mapping the transcode folder to the tmp directory you created, then start plex mine is in tmp/plexram...
  20. or, transcode to ram. I use the following in user scripts (which I found on here) #!/bin/bash mkdir /tmp/PlexRamScratch mount -t tmpfs -o size=4g tmpfs /tmp/PlexRamScratch Whenever I transcoded to just tmp or any already created subfolder it would fill and lock up the system. With a folder of a specified size like this, I'm my experience, It may fill up and halt the transcode the first time it fills the ram, but after (even after reboot) that I've never had any issue with plex doing it's own garbage service and deleting older transcode files (knock on wood). This costs me nothing and doesn't cause any appreciable wear and tear on physical hardware.