Search results

Thanks for sharing. This does give some food for thought. Notable is non of the kernel boot options prevent the display output capture and this is apparently a known issue. Thinking of it, it seems logical to not set virtio-GPU for display under hardware, I now vaguely remember that's how it...

asking for your advice and experience (AMD Radeon VII GPU) when booting a VM with the GPU mapped as virtio-GPU this causes the VM boot screen to be displayed on the console of the server, this is not desirable. after the VM captures the GPU this prevents from switching to a different TTY using...

@zenowl77 you should really just benchmark it from a live system or similar, may take some work to make it work but it will save you headaches and useless efforts, test it as a dedicated device, no Proxmox/vGPU/... involved

Looking at the X299 product page I notice the last BIOS is from 2021, I'd not look much further. One thing you could do is boot the machine with a live system or similar and benchmark hashcat that way on the GPU. I'd not be surprised if the performance you get from this is as high as it is...

looking at this @guruevi could be right the memory lay-out may be causing performance issues (96GB of ram) (32+32+16+16 ?) best is to consult the motherboard manual to find how the ram is assigned and also to check if all ram is compatible also, not all ram slots are equal for any kind of pair...

I'd agree for a 3D benchmark or something else media-heavy, for hashcat I've not seen much variance in compute benchmarks regardless of the slot. Also, unless the system is under stress test or this is indeed loaded to the max any performance issues due to bus constraints are unlikely. In...

if you use the card without vGPU you're likely to see performance similar or at times higher than bare metal, my experience with the Radeon card

MTU is a known source of issues with auto-negotiate, check if there are errors on the interfaces or if duplex is switching for the interfaces. I agree it could be elsewhere, typically poking around low-level and moving up the stack is 'the way' to diagnose network/vendor issues. Mikrotik is also...

UPDATE based on researching logs and error messages journalctl -b all -p warning -f I've come to the "educated assumption" the issue is likely either entirely unknown at this time or it is caused by the Debian VM /dev/sda I/O errors replicating onto the Proxmox VE ZFS leading to system...

which is why i contemplated the MTU may not be well supported or well configured a failing MTU can prohibit auto-renogiation and as such also block the interface to become UP UP

I've only worked with AMD thus far. The configuration of the GPU PCI pass through can be a bit delicate to get things to work well. I wonder if you're doing pass-through configuring all in the VM or if you're using the Proxmox VE resource mapping ? Coincidentally I've noticed what appears to...

okay, check how much of the dedicated RAM is available to the GPU, with the Radeon I'm using this was not always assigned fully and causes issues also, when running hashcat, double-check if the benchmark is actually using the GPU (been there, really)

silly question maybe, did you install the qemu-agent ? was the VM graphics card configured appropiately at the VM config ? you may find reading thru this helpful https://pve.proxmox.com/wiki/NVIDIA_vGPU_on_Proxmox_VE#Enable_PCIe_Passthrough

UPDATE no improvement, similar system "semi-hang" occurance twice already, using proxmox-default-kernel (6.8) (KSM enabled) only TTY1 responded, other TTYn were not visible neither accessible, sysrq keys responded the error message "ZFS rpool unavailable - message: cannot import pool no such...

@babine was this set-up at one point stable and functioning ? Was the MTU validated to be supported across all parts and paths ?

This thread to document what happened and how this was fixed, just in case this can help someone. Running pve-manager/8.4.1/2a5fa54a8503f96d (running kernel: 6.11.11-2-pve) in a single host set-up for a lab environment. The system typically is stable, until it is not. After a few 'hangs' this...

I'll have to check myself then, i don't remember doing this explicitly. Well, guilty. The system hung again this morning. I've now switched back to the 6.8 kernel, assuming the version will increase automatically over time.

well, then, you just answered

Hey Thomas My impression is the freezes happen every three weeks. I'm setting up grafana and other tools to get a better view. I'll update this thread after. Best JL