meina222
-
Posts
449 -
Joined
-
Last visited
-
Days Won
5
Content Type
Profiles
Forums
Events
Downloads
Posts posted by meina222
-
-
6 hours ago, Jaidy said:
Looking at the presentation today, Apple claims that Big Sir is supposed to be significantly faster (at launching apps, switching between them, performance wise etc.) than Catalina. Have you observed this on your hack/MBP?
P.S. when the update to Big Sur arrives, it should go through seamlessly using your EFI, right?
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.
-
1
-
-
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.
-
1
-
-
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 loopbackiface 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 0iface 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/vmbr0auto lo
iface lo inet loopbackiface 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 0iface eno1 inet manual
-
Could you post the outputs of the following in Proxmox
1) ls -l /sys/class/net
2) less /etc/network/interfaces
-
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-d52d5fe538472. 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.
-
23 minutes ago, Jaidy said:
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> -
4 hours ago, iosengineer said:
Fascinating — thank you so much @meina222 for your time sharing these details. The Above 4G discussion is interesting, as:
- I've had it on (both in general, and recommended by Dortania guide)
- I just tried disabling it, and it actually causes fail-to-boot on my crappy barebones MMIO-less config (it boots again after enabling Above 4G!)
-
I haven't tried Above 4G disabled with your config, but may wait until I have an hour or two and validate MMIO (out of respect for all of your time).
- Not sure how I got an old copy! I'm 90% sure I'd downloaded it from your post just a couple days ago, but I could have made an error.
While I've expressed some degree of hastiness, the last thing I want is to be another...ahem, "Clover-type" user...who doesn't care about the details. I'd been away from Hackintosh since 2006 (I had a rockin' build, lol). It was specifically OpenCore, and its rigorous first-principles-based philosophy, which I discovered almost exactly a year ago and motivated each of the C246 / W480 / TRX40 (mostly Proxmox) builds.
So I apologize for any hesitancy to dive into MMIO, but especially now that I understand that it's expected for NVRAM to be broken without that memory mapping—that gives me enough confidence that I'm relatively close and it's worth the time.
That said it might take me a couple days, just due to a couple life / work things going on, but I'll report back ASAP. Additionally, I'll be actively following all the posts here for the forseeable future, and deeply appreciate every one of you for your thoughtful engagement with the community!
Meanwhile, one project today has been "fabricating" custom copper heatsinks for my 2x 380GB Optane 905p's, which are being used as the special vdev (in mirror) for both my 4x 970 Evo Plus "working" ZFs pool, and 16x SAS3 HDD main ZFS pool. I need to make a big cut to the large one tomorrow. The controllers are not at the same z-height, and I'd like to take my router bit to it for a monoblock fit, but found the small 20mm x 20mm ones can keep the controllers plenty cool with modest airflow. Over 9W in an M.2 form factor isn't the best idea!
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?
-
1
-
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 -
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.
-
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.confless 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 btusbless 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:1533For 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/unbindYou 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.
[Discussion] - TRX40 Bare Metal - Vanilla Patches
in General
Posted
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