fabiosun

I did..in my case yes..no improvement but it is latest available so could have some benefit I cannot see by now I f you are unsure stay with old version

ok solved 🙂 root@pve:~# pveversion -v proxmox-ve: 6.2-1 (running kernel: 5.4.34-1-pve) pve-manager: 6.2-4 (running version: 6.2-4/9824574a) pve-kernel-5.4: 6.2-1 pve-kernel-helper: 6.2-1 pve-kernel-5.4.34-1-pve: 5.4.34-2 ceph-fuse: 12.2.11+dfsg1-2.1+b1 corosync: 3.0.3-pve1 criu: 3.11-3 glusterfs-client: 5.5-3 ifupdown: 0.8.35+pve1 ksm-control-daemon: 1.3-1 libjs-extjs: 6.0.1-10 libknet1: 1.15-pve1 libproxmox-acme-perl: 1.0.3 libpve-access-control: 6.1-1 libpve-apiclient-perl: 3.0-3 libpve-common-perl: 6.1-2 libpve-guest-common-perl: 3.0-10 libpve-http-server-perl: 3.0-5 libpve-storage-perl: 6.1-7 libqb0: 1.0.5-1 libspice-server1: 0.14.2-4~pve6+1 lvm2: 2.03.02-pve4 lxc-pve: 4.0.2-1 lxcfs: 4.0.3-pve2 novnc-pve: 1.1.0-1 proxmox-mini-journalreader: 1.1-1 proxmox-widget-toolkit: 2.2-1 pve-cluster: 6.1-8 pve-container: 3.1-5 pve-docs: 6.2-4 pve-edk2-firmware: 2.20200229-1 pve-firewall: 4.1-2 pve-firmware: 3.1-1 pve-ha-manager: 3.0-9 pve-i18n: 2.1-2 pve-qemu-kvm: 5.0.0-2 pve-xtermjs: 4.3.0-1 qemu-server: 6.2-2 smartmontools: 7.1-pve2 spiceterm: 3.1-1 vncterm: 1.6-1 zfsutils-linux: 0.8.3-pve1 root@pve:~# it was simple..a file....kvm.conf 🙂 🙂 🙂 no improvement for our common problem for now I would like also to remark: useful file for my rig to modify after a clean Proxmox VE 6.2 iso: etc/modules vfio vfio_iommu_type1 vfio_pci vfio_virqfd etc/modprobe.d/kvm.conf options kvm ignore_msrs=1 /etc/default/grub.cfg quiet iommu=pt amd_iommu=on then I have used my previous VM.conf file recreating in it only EFI disk

Ok, it is a not new kernel problem related..Probably new QEMU has some conflict with our bootloaders... for now stay away from this or try with a solid backup

do not update for now now also my minimal Vm hangs on ++++++++ end seed both with clover 5107 and opencore 0.58 try to revert to old kernel by now i hope it is enough to start again my VM 😂 upgrading deleted my lvm.conf file so this was the reason for the hang on ++++++++ phase (MSR related)

https://forum.proxmox.com/threads/proxmox-ve-6-2-released.69647/

@AllubzV this could be the command (boot parameter) for me to test...adding where? they say boot argument.. I have tested in grub.cfg with no success for now pcie_no_flr=1022:148c,1462:cb60

to all: Maybe it is not well shown in the guide but you have to remember a thing: Clover/OpenCore iso image we upload on Proxmox appropriate folder if associated in our VM config it become a normal bootable EFI as we have in a "real" hackintosh So, if you modify it you automatically modify uploaded iso file in proxmox. ie my clover.iso I have in proxmox now inside has Opencore 0.59 boot loader.. So pay attention on this. In my experience is better to have uploaded a clean and simple working iso you can use only for repair bad things gone wrong, also in my case I have a commented line in VM with opencore/clover working iso that I never modify Usually I boot from EFI in my NVME drive, when things go bad (for osx I mean) I uncomment that line and from OVMF Proxmox bios I choose that iso to boot fine.

@iGPU scp command are in the guide and then are also obsolete in some case from an advice @Rocket88gives about using FileZilla ftp client(if you search you can find easily) link here A remainder as you did is good too 🙂 about lane sharing..this could be the big task for all of us togheters multiple "bridge" connection we have.. I think it is also an unexplored territory also for Proxmox guy and maybe in many case Windows VM is not affected from the same our problems because in there more supported stuff is (virtio drivers, spice and so on) I am convincing myself ( 🙂 ) that audio problem is not related to my poor knowledge but it is more a "system" problem I can have it perfectly working but it is not stable at all as it should be and also how Nvidia DP/Hdmi is. I would like to share an example: with many tries I have "a working" Realtek audio I launch DaVinci Resolve to produce some video you can find in macOS86 you tube channel edit video cutting, scribbling audio perfectly.. I put a cross dissolve ( a simple cross dissolve to insert macOS86 logo as a super on main video ) audio scratch during cross dissolve effect... Our system (mine in particular) can work with multiple 8k layer without any problems) but using this problematic audio it fails (I repeat..with DP audio is perfect) so it should be OSX audio driver not working well with VM previously configured part .. Searching on the net many talking about problematic audio in VM but no one gives a solution to try

Good, If you think it could help other people and if you want , describe your procedure to have it working 🙂 I have had private conversation with many AMD radeon VII and seems some Radeon VII card has not a UEFI BIOS It is not confirmed directly by me, but it is a sort of "rumours", and this should be the cause of many AMD GPU card users.

@AllubzV take a look and compare with yours (I would like also others TRX40 users put their similar datas to compare) 04:00.3 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] Starship USB 3.0 Host Controller [1022:148c] Subsystem: Micro-Star International Co., Ltd. [MSI] Starship USB 3.0 Host Controller [1462:7c60] 23:00.3 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] Starship USB 3.0 Host Controller [1022:148c] Subsystem: Micro-Star International Co., Ltd. [MSI] Starship USB 3.0 Host Controller [1462:7c60] Kernel driver in use: xhci_hcd 23:00.4 Audio device [0403]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse HD Audio Controller [1022:1487] Subsystem: Micro-Star International Co., Ltd. [MSI] Starship/Matisse HD Audio Controller [1462:cb60] Kernel driver in use: vfio-pci 46:00.1 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] Matisse USB 3.0 Host Controller [1022:149c] Subsystem: Advanced Micro Devices, Inc. [AMD] Matisse USB 3.0 Host Controller [1022:1486] Kernel driver in use: vfio-pci 46:00.3 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] Matisse USB 3.0 Host Controller [1022:149c] Subsystem: Advanced Micro Devices, Inc. [AMD] Matisse USB 3.0 Host Controller [1022:148c] Kernel driver in use: vfio-pci And focalise also on Subsystem data (check also your BIOS AGESA, TRX40 ones are not updated to the last patch). Now, as you have seen FLR patch is not perfectly calibrated for TRX40 users and if you follow below link I have inserted on Proxmox forum, Stefan_R (a proxmox forum staff guy) says we have to do some others step because "we are experiment on the joy to use bleeding edge new hardware" 🙂 FLR patch was done some months ago and follow leveltech1 comment in some cases is possible to insert via kernel command (in my case it not was working) @pavo compiled that patch in a kernel (which is not the one suggested by Fabian) and it is available on his GitHub In my case is not working and for some x570 users is working partially So our goal should be how to compile new Kernel you can find in Proxmox git and then to understand if it possible to insert on a kernel line command FLR patch Proxmox Stefan_R advice level1techs FLR patch discussion Proxmox git for latest Kernel As last information I would like to share, I can pass also 23:00.4 as you can see in my above box (it uses vfio-pci kernel )but audio is problematic I can have a working internal audio via matisse audio controller or with a simple usb audio adapter bought to test this problem. Audio works..but it is not perfect (I loose it, some time is scratchy an so on) some time is perfect but usually if I change audio source from ie a video to a mp3 file ..I loose it For this I said before no ready for a professional use Nvidia Dp/hdmi is perfect. My idea is a negative idea in this subject (I hope to be very wrong on this). problem for me is due Audio osx system driver and how it is interact with trx40 CPU. In Proxmox Windows 10 64 bit VM, same linux configuration, internal audio (USB 2.0 Realtek) is perfect As last last ( 🙂 ) information I would like to advice to test audio problem (it is valid also for other problem you can have) to test with a minimal set of passed controllers.. I pass for this task only NVME controllers where I have my OSX disk and then I pass mouse/keyboard as single USB ports. To have proxmox distro installed on an USB disk could be useful to pass fine all your Sata or NVME controllers to OSX (I use back type C port of my motherboard) and doing this I loose possibility to pass my ASMedia USB controller to OSX, but both ports on it are working (simple USB port passthrough)

ciao Klaus l'errore del cellhophane e' da arresto ma un dissipatore lga 2011-v3 puo' essere compatibile

@klausse hai preso la piastra dal link di cui sopra vedi come si chiama la piastra sia dal titolo che dalla scatola x299 che significa LGA 2066 se ti arriva altro non la aprire nemmeno 🙂

No differences i think problem is Proxmox/osx related in a proxmox windows environment it works as it should be

@Driftwoodpassing radeon should be unrelated to your problem Have you passed some network device? I mean the one you have started proxmox when you install it first time? if so you should do a bridge with it ( I am not confident to how to this and you have to manage at /hosts/interface or similar simple way is to stay with initial default VMware ethernet controller disabling passed network controller in your VM config

@here USB audio partially solved.... verify few things then I will expose it how I did. I repeat USB audio not internal Realtek USB 2.0 motherboard audio for now Not usable for production.

hi @Rocket88thank you for your message above for to do list 1) is a common research because OSX misses Qemu Agent so if you shutdown OSX linux will be on I think you can avoid something you used..maybe in your blacklist.conf file to pass "hangs after Ramdisk message" (it could mean you have blacklisted your GPU driver so you need to run VM from another pc/device Only you can verify this When you have time post here benchmark for your system, It could be useful for other users thank you again for posting your experience!

caio, no non trovo niente di banale nelle domande. e' che un minimo visto che fare hack non e' proprio alla portata di tutti..un minimo dicevo bisogna fare da se..anche per non mandare maledizioni agli altri 🙂 comunque si mi riferisco alla lista di CPU supportate da verificare sulla piastra che sceglierai

non credo che ci siano produttori giapponesi.. pero' la marca e' ok devi leggere nel support sul sito della piastra che scegli

no per la tua CPU (LGA 2066=x299 e' il socket) pero' non so se le nuove revisioni di X299 supportano le "vecchie" CPU bene..penso di si pero' controlla

Il livello più' o meno e' quello Guarda le caratteristiche di ognuna e vedi se c'e' qualcuna delle stesse che ha cose on board che ti interessano di più' se prende in un futuro di espanderti io ho avuto ASUS ed Gigabyte Con Asus meno problemi ad esempio per lo sleep Ti ho messo la Asrock come preferenza perché' mi sembra la migliore come prezzo / prestazioni verifica bene nei BIOS (di quella che sceglierai) se hai il supporto per la tua CPU attuale

Il tuo socket è lga 2066 (x299) su questo socket con un bios aggiornato ci puoi mettere anche un 10980xe

Stacchi alimentazione metti su off l’alimentazione tieni premuto il pulsante di accensione per 10s prova pure a scollegare tutti I sata e vedere che accade vedi se le ventole partono

rismontala e vedi se non si e' piegato qualche pin o sporcato di pasta se non hai sentito odori di bruciato..e' difficile rompere una piastra prova pure a togliere la batteria tampone e fa scaricare i condensatori bene.. insomma le solite cose se non le hai fatte

cmq questa non mi dispiace: https://www.amazon.it/PB-Asrock-X299-Steel-Legend/dp/B07ZSSTSDB/

sei sicuro che e' rotta? perche' sul nuovo con quella cifra non ci prendi niente di meglio..anzi..