meina222
-
Posts
449 -
Joined
-
Last visited
-
Days Won
5
Content Type
Profiles
Forums
Events
Downloads
Everything posted by meina222
-
I’d have done that till I read that it won’t support eGPUs. Will wait for a more expandable model as I have no use for a mini or ultraportable MacBook otherwise
-
Mostly marketing noise. No significant benchmark differences or perceived responsiveness in my experience. Perhaps, it's the point to add that the whole Apple Silicon release is disappointing. A Mac "Pro" laptop with a max of 16G memory? This is a long way from a true "Pro" product -rather a bloated iPad with a keyboard and a neural chip.
- 3,920 replies
-
- 1
-
-
- amd vanilla patches
- amd kernel patches
- (and 3 more)
-
As last step, before you pass-thru, write-down the MAC address of the card you pass thru. Check the output of: ip link and find the entry for eno1 The mac address will look like for example (made up the HEX string separated by :) link/ether a4:2e:79:bb:21:ff You need to write down a4:2e:79:bb:21:ff (you will see your own MAC address of course this is dummy) as this will go in your OpenCore config.plist in binary format as described by Dortania. You can use XCode to encode it.
-
To test which one is which, unplug the cables 1 at a time (assuming both are connected) and see which one loses your Proxmox host network/internet connection and which one is ignored. The one that is not affecting Proxmox will be the 44:00 one you pass-thru. This 44:00 card you give the VM will then connect to the virtual network bridge/gateway defined by Proxmox to get internet auto lo iface lo inet loopback iface enp69s0 inet manual auto vmbr0 iface vmbr0 inet static address 192.168.1.14 netmask 255.255.255.0 gateway 192.168.1.1 bridge_ports enp69s0 bridge_stp off bridge_fd 0 iface eno1 inet manual
-
Based on below you need to add to VM config (assuming hostpci1 is free in your VM config if not use next free one say hostpci2): hostpci1: 44:00,pcie=1 To verify make sure that 44:00 shows up in your ID's when you do lspci | grep -i eth you should see 2 ethernets and one of them will be 44:00 and the other 45:00. Try passing 44:00. Is that your 10G card or 1G card? You may need a kext / patch in macOS if it is Aquantia. @fabiosun, has the same motherboard so he can share what kext / patch is needed, I don't have this device. The other one may be supported by default. Explanation: The yellow ethernet from your 1st output (PCI id 45:00) corresponds to enp69s0 which is used as the bridge/gateway for your Proxmox host. You need to pass the free card 44:00. If you want to swap you need to change the Proxmox host network config below. root@dtk:~# ls -l /sys/class/net total 0 lrwxrwxrwx 1 root root 0 Nov 6 17:17 eno1 -> ../../devices/pci0000:40/0000:40:01.1/0000:41:00.0/0000:42:04.0/0000:44:00.0/net/eno1 lrwxrwxrwx 1 root root 0 Nov 6 17:17 enp69s0 -> ../../devices/pci0000:40/0000:40:01.1/0000:41:00.0/0000:42:05.0/0000:45:00.0/net/enp69s0 lrwxrwxrwx 1 root root 0 Nov 6 17:17 fwbr100i0 -> ../../devices/virtual/net/fwbr100i0 lrwxrwxrwx 1 root root 0 Nov 6 17:17 fwbr101i0 -> ../../devices/virtual/net/fwbr101i0 lrwxrwxrwx 1 root root 0 Nov 6 17:17 fwln100i0 -> ../../devices/virtual/net/fwln100i0 lrwxrwxrwx 1 root root 0 Nov 6 17:17 fwln101i0 -> ../../devices/virtual/net/fwln101i0 lrwxrwxrwx 1 root root 0 Nov 6 17:17 fwpr100p0 -> ../../devices/virtual/net/fwpr100p0 lrwxrwxrwx 1 root root 0 Nov 6 17:17 fwpr101p0 -> ../../devices/virtual/net/fwpr101p0 lrwxrwxrwx 1 root root 0 Nov 6 17:17 lo -> ../../devices/virtual/net/lo lrwxrwxrwx 1 root root 0 Nov 6 17:17 tap100i0 -> ../../devices/virtual/net/tap100i0 lrwxrwxrwx 1 root root 0 Nov 6 17:17 tap101i0 -> ../../devices/virtual/net/tap101i0 lrwxrwxrwx 1 root root 0 Nov 6 17:17 vmbr0 -> ../../devices/virtual/net/vmbr0 auto lo iface lo inet loopback iface enp69s0 inet manual auto vmbr0 iface vmbr0 inet static address 192.168.1.14 netmask 255.255.255.0 gateway 192.168.1.1 bridge_ports enp69s0 bridge_stp off bridge_fd 0 iface eno1 inet manual
-
Could you post the outputs of the following in Proxmox 1) ls -l /sys/class/net 2) less /etc/network/interfaces
-
@dtek I used the Dortania guide. https://dortania.github.io/OpenCore-Post-Install/universal/iservices.html Basically you need to do this: 1. Find out the PCI id of your ethernet card in Proxmox and pass it through to the VM. Make sure your Porxmox host can get its connectivity from another place (2nd ethernet, wireless) As an example, the highlighted id below is one my two ethernets (the 2nd I leave to Proxmox for host connectivity). args: -device isa-applesmc,osk="ourhardworkbythesewordsguardedpleasedontsteal(c)AppleComputerInc" -smbios type=2 -device usb-kbd,bus=ehci.0,port=2 -cpu host,+invtsc,vendor=GenuineIntel balloon: 0 bios: ovmf boot: cdn bootdisk: virtio0 cores: 64 cpu: Penryn efidisk0: aorus:vm-101-disk-1,size=1M hookscript: local:snippets/vmhook.sh hostpci0: 43:00,pcie=1,x-vga=1,romfile=vbios.bin hostpci1: 86:00,pcie=1 hostpci2: 85:00,pcie=1 hostpci3: 88:00,pcie=1 hostpci4: 02:00,pcie=1 hugepages: 1024 ide2: local:iso/OpenCoreBeta.iso,size=150M machine: q35 memory: 196608 name: bigsur numa: 1 ostype: other scsihw: virtio-scsi-pci smbios1: uuid=4b5493a6-6a73-48b7-8ce5-2be70a66a383 sockets: 1 vga: none virtio0: aorus:vm-101-disk-0,cache=unsafe,discard=on,size=250G vmgenid: 18d68c27-3a62-4059-9280-7f86a572af59 vmgenid: 0c7cc702-74ba-4d8e-ba4b-d52d5fe53847 2. Get the ROM/MAC address of the ethernet device you passed-thru and specify it in your OpenCore config.plist as described in the Dortania guide 3. Make sure your enX (e.g. en0) device matching the card is "primary" in MacOS as described in the guide 4. Make sure NVRAM works in MacOS as described in the guide When done, you can activate iMessage. Worked for me.
-
Not getting this, but looking at the diff, here's a small difference - the highlighted key is new in OC 0.6.3 and did not exist in 0.6.2 <key>PlatformInfo</key> <dict> <key>Automatic</key> <true/> <key>CustomMemory</key> <false/> <key>Generic</key> <dict> Can you try with that? For the sake of completeness another new key is: <key>Output</key> <dict> <key>ClearScreenOnModeSwitch</key> <false/> <key>ConsoleMode</key> <string></string> <key>DirectGopRendering</key> <false/> <key>ForceResolution</key> <false/> <key>IgnoreTextInGraphics</key> <false/> <key>ProvideConsoleGop</key> <true/> <key>ReconnectOnResChange</key> <false/> <key>ReplaceTabWithSpace</key> <false/> <key>Resolution</key> <string>Max</string> <key>SanitiseClearScreen</key> <false/> <key>TextRenderer</key> <string>BuiltinGraphics</string> <key>UgaPassThrough</key> <false/> </dict>
-
Wow. I didn't bother to remove the shroud but I made sure I have well ventilated case and 3 fans blowing this. I run my Proxmox VM ZFS pool on 4 ssd's there - and I have never seen temps spike too much. Having the NVMe's run a bit warm is actually fine, but you really want to make sure they don't overheat - perhaps you have big write loads in mind?
- 3,920 replies
-
- 1
-
-
- amd vanilla patches
- amd kernel patches
- (and 3 more)
-
Glad it worked out. On the reset topic - you can also replace "reboot" with "shutdown -f now" in the earlier version of my hookscript. Thus, when you shutdown your VM, this will shut your host - clearly a misuse of the VM concept as you want your host to be up, but the reset bug (depending on your usage of the GPU) might force this to be the best option. I use the VM as a desktop proxy and not as a multi-VM server right now so such setting works for me. Another thing in my hook is "tasksets" - depending on how many CPU's you pass to the VM, you can change this (mine is 0-63 in the hook as I have 128 logical cores and I pass 64 of them). You have 64 logical cores (SMT on 32 cores) and if you pass 32 of them to the VM, you can tweak this part to say 0-31. This will "pin" your VM tasks to these cores, which may bring some performance benefits (unlikely to be noticed in most benchmarks). Finally if you ever pass ethernet, you may need different networking configs for your host - I recommend using VM ethernet due to this as it is fast enough.
-
@iosengineer - I just diffed the file with my name in it with my booting config.plist. Double check with your copies - I could have overlooked something. Also. it's worthwhile noting I boot Big Sur (so my CPU patches are reduced to that effect). It may or may not work with Catalina with these patches - another thing to keep in mind, hence why cross checking w another config is best. And if above 4G works for you, keep it, but this means my MMIO addresses won't be good even with same BIOS, so you will need to re-derive them.
-
@Ploddles, you may also want to share your EFI with @iosengineer - between the 2, I am sure he can come up with something that works based on his hardware. But even between same motherboards it's clear that BIOS versions, BIOS settings, and PCI slot configuration will make configs incompatible - you have to build it yourself based on your needs.
-
Your best bet is to wait for the new Radeon 6000 and hope they fixed it there. There are some older AMD GPUs that reset but nothing newer than a few years at this point (except maybe a few RX 580 Sapphire Pulse models, but have only read anecdotes of that, not verified it and would not trust to buy based on that alone). New radeon 6000 will be out by end of Nov and we'll know very soon if it resets.
-
For now you can remove everything from the hook script except these (even though vmid is not used it may come handy later): The critical one is the frame buffer unbinding and then reboot is optional - you normally don't want to reboot but I do it as the GPU can't reset. #!/bin/bash vmid="$1" phase="$2" if [[ "$phase" == "pre-start" ]]; then echo 0 > /sys/class/vtconsole/vtcon0/bind echo 0 > /sys/class/vtconsole/vtcon1/bind echo efi-framebuffer.0 > /sys/bus/platform/drivers/efi-framebuffer/unbind #elif [[ "$phase" == "post-stop" ]]; then echo "Post-stop VM $vmid" reboot fi
-
@iosengineer, Not sure which version of config plist you had of mine, but it may be pretty old. I see major differences. Could you try this reduced one (after you verify your MMIO list and replace the addresses and fill in your serials). No need to use MacPro7,1 - I do it just because I went thru USB mapping using that, but iMacPro1,1 is easier to work with. Attached are also the SSDT's in the config plist. One of them adds NVRAM, but you need to make sure you have the right MMIO. Also this config.plist works w OC 0.6.2 and OC 0.6.3. config.plist.zip ACPI.zip
-
Yes, you need the true rom file. I would not move the GPU yet. In fact the GPU being in slot 2 may be an advantage - try even w/out the rom file as I think shadowing the rom may only be required in slot 1. Also if the VM fails to start - check the host log Syslog as I described above. You can do it from the web GUI in realtime.
-
Basically when you're all done and reboot you need to be able to succeed from your primary display to do this echo 0 > /sys/class/vtconsole/vtcon0/bind & echo 0 > /sys/class/vtconsole/vtcon1/bind & echo efi-framebuffer.0 > /sys/bus/platform/drivers/efi-framebuffer/unbind This will block your main display but then you can use the web console to start the VM and the card should switch over to the VM bios after 20-30 seconds and you should see the VM bringing your display back alive. When you verify this, you can use the hook again (but don't use other stuff in this hook as it is specific to core count and network setup). Basically the way I operate is: 1. Start Proxmox 2. Login 3. run "qm start [vmid]" (whichever VM I like to start) 4. Screen blocks as the hook unbinds the buffer but comes back alive when the VM takes it over and I see the VM booting and GPU being taken over host. 5. Since AMD reset bug makes the GPU unclaimable by the host, you cannot restart the VM until you reboot the host, but this is a 2-ary issue.
-
Not that I see yet - other than the GRUB cmd line I posted above. It's been a while since I put this and I don't recall the significance, but noticed the difference. And throw in your blacklist blacklist amdgpu for good measure.
-
Here's my grub less /etc/default/grub # If you change this file, run 'update-grub' afterwards to update # /boot/grub/grub.cfg. # For full documentation of the options in this file, see: # info -f grub -n 'Simple configuration' GRUB_DEFAULT=0 GRUB_TIMEOUT=5 GRUB_DISTRIBUTOR="Proxmox Virtual Environment" GRUB_CMDLINE_LINUX_DEFAULT="quiet amd_iommu=on iommu=pt default_hugepagesz=1G hugepagesz=1G hugepages=192" GRUB_CMDLINE_LINUX="fbcon=rotate:0" # Disable os-prober, it might add menu entries for each guest GRUB_DISABLE_OS_PROBER=true # Uncomment to enable BadRAM filtering, modify to suit your needs # This works with Linux (no patch required) and with any kernel that obtains # the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...) #GRUB_BADRAM="0x01234567,0xfefefefe,0x89abcdef,0xefefefef" # Uncomment to disable graphical terminal (grub-pc only) #GRUB_TERMINAL=console # The resolution used on graphical terminal # note that you can use only modes which your graphic card supports via VBE # you can see them in real GRUB with the command `vbeinfo' #GRUB_GFXMODE=640x480 # Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux #GRUB_DISABLE_LINUX_UUID=true # Disable generation of recovery mode menu entries GRUB_DISABLE_RECOVERY="true" # Uncomment to get a beep at grub start #GRUB_INIT_TUNE="480 440 1" Try updating your grub with GRUB_CMDLINE_LINUX_DEFAULT="quiet amd_iommu=on iommu=pt"
-
Here's my /etc/modprobe.d content -rw-r--r-- 1 root root 205 Jul 18 17:54 blacklist.conf -rw-r--r-- 1 root root 26 Jun 21 22:54 kvm.conf -rw-r--r-- 1 root root 171 May 10 15:06 pve-blacklist.conf -rw-r--r-- 1 root root 148 Jul 5 01:15 vfio.conf less blacklist.conf blacklist radeon #blacklist nouveau #blacklist nvidia blacklist amdgpu blacklist snd_hda_codec_hdmi blacklist snd_hda_codec blacklist snd_hda_core blacklist snd_hda_intel blacklist iwlwifi blacklist btusb less vfio.conf options vfio-pci ids=1002:731f,1002:ab38 disable_vga=1 options vfio-pci ids=1022:148c options vfio-pci ids=1022:149c options vfio-pci ids=8086:1533 For vfio.conf, follow this guide as your id's will be different: https://pve.proxmox.com/wiki/PCI(e)_Passthrough My theory is that you don't disable the host taking over your GPU and cannot unbind the efi framebuffer as a result.
-
As long as the id 05:00 is correct, and the vbios.bin file is the real rom and located in /usr/share/kvm/ then it should not matter what pci slot you specify. In one of my VMs I use hostpci3 even though my GPU is in Slot 1. You need to be able to unload the framebuffer though (unless you have a 2nd GPU lying around). Do you blacklist your radeon driver?
-
Yeah - you need the real vbios - so if you can't find it you need to dump it (which is recommended anyways). Retry with new file. But I am more concerned with the inability to unbind the framebuffer - as if it is already unbound. If you can't successfully do that, the guest cannot take over the GPU.
-
Also could you share the output of less /etc/default/grub Want to make sure you're not disabling efi framebuffer. Some guides online tell you to do so and that might explain the error you get.
-
When you click on your host under 'Datacenter' in Proxmox web gui, you can go under 'System' in the tab and check the log of the Proxmox host under 'Syslog'. But basic things 1st - your VM config is located in /etc/pve/qemu-server/ file will be called [vmid].conf where [vmid] is the name of your VM Comment out the GPU passthru for now by putting a # in front of the hostpci line that has your GPU id. Also replace vga: none with vga: vmware Are you able to start your VM then? Hint: you can manually start the VM by "qm start [vmid]" or just use the web interface. also disable the hook for now (comment with same # in front of line). We want to make sure your VM starts fine w/out GPU passthru.
-
Are you able to connect to the Proxmox host remotely? Can you open a console via the web interface, so when you disable the GPU, you can recover? If so, can you try manually running each of the lines, and let me know which fails. Do not copy my hook verbatim - I have stuff there that requires 128 CPUs, you have a 3970x. Just use the gpu section. But for now run manually: echo 0 > /sys/class/vtconsole/vtcon0/bind echo 0 > /sys/class/vtconsole/vtcon1/bind echo efi-framebuffer.0 > /sys/bus/platform/drivers/efi-framebuffer/unbind You can reboot from the web console to recover display or try to manually rebind. Need to step away for 30 min. Will check back in a bit.