Jump to content
XPEnology Community

Pedulla

Rookie
  • Posts

    8
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Pedulla's Achievements

Newbie

Newbie (1/7)

0

Reputation

  1. uname -a Linux DVA3221 4.4.180+ #42962 SMP Mon May 29 14:37:35 CST 2023 x86_64 GNU/Linux synology_denverton_dva3221 running as a VM on PVE 8.03 with gpu passthrough. Works great. Is it possible to install the QEMU Guest Agent on the DVA3221?
  2. Thanks to @Orphée and others here, if got it going on PVE 8. Key settings for me: - Separate (additional) GTX1650 from host system GPU. - Brand didn't seem to matter except for passthrough parameters (see below) - VM config in PVE 8 is odd to me; I've not used this before. System: Dell Prec. 7910 Host grub boot line (/etc/default/grub) GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_iommu=on iommu=pt pcie_acs_override=downstream multifunction initcall_blacklist=sysfb_init vfio-pci.ids=10de:1f82" Where "vfio-pci.ids=10de:1f82" is derived from "lspci -nn | grep VGA" The VM was the tricky part for me: Couldn't get the Primary GPU option to work till I changed the display to VirtIO-GPU. Hope this helps. Note that DVA3221 supports multiple network cards so you can isolate your chinese camera network Also note that in my previous attempts I could get the GPU to "show up" in the info tab of DVA3221 and nvidia-smi would show the detect code loaded, but any use of the GPU would segfault the GPU code for object/face detection, and stall stall the system. Now I'll get to work on the storage part of this equation. Thanks everyone for the input.
  3. Do you think it's a manufacturer specific issue? Your's is a HP video card, ours are ASUS....
  4. sudo lspci -nnkvq -s 01:00.0 Password: 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation TU117 [GeForce GTX 1650] [10de:1f82] (rev a1) (prog-if 00 [VGA controller]) Subsystem: ASUSTeK Computer Inc. Device [1043:8773] Flags: bus master, fast devsel, latency 0, IRQ 16 Memory at fb000000 (32-bit, non-prefetchable) [size=16M] Memory at d0000000 (64-bit, prefetchable) [size=256M] Memory at e0000000 (64-bit, prefetchable) [size=32M] I/O ports at 5000 [size=128] Expansion ROM at fc000000 [disabled] [size=512K] Capabilities: [60] Power Management version 3 Capabilities: [68] MSI: Enable- Count=1/1 Maskable- 64bit+ Capabilities: [78] Express Legacy Endpoint, MSI 00 Capabilities: [100] Virtual Channel Capabilities: [250] Latency Tolerance Reporting Capabilities: [128] Power Budgeting <?> Capabilities: [420] Advanced Error Reporting Capabilities: [600] Vendor Specific Information: ID=0001 Rev=1 Len=024 <?> Kernel driver in use: nvidia Yet... Should be working, no?
  5. Correction, vehicle and face recognition both are causing seg-faults using the K4000 passed through. I thought it was a little too good to be true. So I grabbed an ASUS Phoenix Series 1650 and through it in and took out the K4000 now I'm seeing the same symptoms as @polkue. The info tab in the DVA3221 shows no GPU install even though lspci -k shows: 00:10.0 Class 0300: Device 10de:1f82 (rev a1) Subsystem: Device 1043:8773 Kernel driver in use: nvidia So why wouldn't the DVA3221 not see the GPU? dmesg on the DVA3221 reports: [ 3418.850221] NVRM: GPU 0000:00:10.0: rm_init_adapter failed, device minor number 0 [ 3424.089267] NVRM: GPU 0000:00:10.0: RmInitAdapter failed! (0x23:0x56:515) Any clues?
  6. So just for grins I went and installed Proxmox 8 on an Intel based dual CPU system with a Nvidia Quadro K4000 I picked up used. (Dell Precision 7910) Then spun up a DVA3221 and passed through the K4000 to the VM. It appears to be working with no reported errors. Just FYI...
  7. I just thought that the virtual environment presented to the boot loader might change in the new version, that's all.
  8. Spun up my first DA3662 , then a DVA3221 (w/o surveillance) up on Proxmox 7 server with EPIC processors. Pretty cool, pretty easy. I saw that the DVA3221 "should" not run on the EPIC processor because of the MOVBE instruction; it's running but I'm not pushing my luck. That said, Proxmox 8 is out with QEMU 8 which has a new x86-64-v2-AES processor type. Will that resolve the issue with the MOVBE instruction when the Proxmox server hardware is EPIC? I'm new to this, so this question might be dumb, but a new redpill is needed for Proxmox 8, right? Thanks
×
×
  • Create New...