Jump to content

meina222

Donator
  • Posts

    449
  • Joined

  • Last visited

  • Days Won

    5

Everything posted by meina222

  1. @Driftwood - what you described above pretty much happened to me too a week ago (on an older OC EFI based on @iGPU's original post). I went from bottom to top, 1st 2 were enabled and booted fine, then next 2 I had to disable, then managed to enable all the rest. At this point I could get the click on shutdown and subsequent reboot (no click before, just silent reboot) but then my rescue USB and no other EFI worked after a while - can't remember anymore if it was immediate. I ended up flashing BIOS which was probably unnecessary.
  2. @tsongz - thank you. Yes, I believe this works only on Vega cards. Fabian from Proxmox has Navi reset 5.8.3 kernel, which I suspect involves the power switch - I built that myself on a lower 5.7.x kernel a couple of months back, and didn't quite work for my 5700XT, but I can retry with the 5.8.3.
  3. Mine is incidentally the same pcie id but I have 1 GPU in slot 1 and I have to dump the vbios and specify the path in the VM config. I decided to give up on the 2nd GPU because I don't have the need to run 2 VMs (or at least not 2 VMs with acceleration). So what kind of reset patch is that? The only one I tried involved the power clicking. And what does root/cmds/reset do?
  4. @tsongz - good to hear about the reset. From what I recall you use single GPU and unload the framebuffer from the host at startup of VM. Do you then give it back to the host? Right now I've configured my hook script to shutdown the host when I shutdown the VM but if the reset patch allows you to reboot more cleanly, then I want to try single GPU and reset + giving back the framebuffer to the host. Do you mind sharing your hook?
  5. Thank you. Yes, I want to retry to whole thing - need to find some time, busy week for me. I will rebuild the EFI from scratch and redo MMIO and might try to guess an initial pattern similar to your file.
  6. @fabiosun - do you believe SSDT's + OC 6.1 are critical to the shutdown (e.g. did you combine @iGPU and @Pavo suggestions) or did you achieve this purely by playing with MMIO?
  7. @Pavo - I have (and older) MacBook Pro late 2012 running Catalina so I could generate a dump on that. If it's preferable to use iMacPro I could probably get access to do that. How do you force dumps? In particular, how can I force it to dump on sleep and shutdown. Is this link helpful in figuring that out? https://craftware.xyz/tips/Debug-kernel-panic.html
  8. @Ploddles - I ended up in a similar situation (don't know how) where I could no longer boot in any EFI. I haven't retried yet after refreshing BIOS - I want to build it from scratch this time around but not sure it's worth it if shutdown and restart not working. I don't see any benefit except more ports and maybe the TB card.
  9. @fabiosun, here's mine from an experiment I did about a week ago before my install became corrupted somehow 39:527 00:005 OCABC: MMIO devirt start 39:530 00:003 OCABC: MMIO devirt 0xE2100000 (0x81 pages, 0x8000000000000001) skip 0 39:534 00:003 OCABC: MMIO devirt 0xE3180000 (0x81 pages, 0x8000000000000001) skip 0 39:537 00:003 OCABC: MMIO devirt 0xEF100000 (0x181 pages, 0x8000000000000001) skip 0 39:541 00:003 OCABC: MMIO devirt 0xFA180000 (0x81 pages, 0x8000000000000001) skip 0 39:544 00:003 OCABC: MMIO devirt 0xFA300000 (0x100 pages, 0x8000000000000001) skip 0 39:548 00:003 OCABC: MMIO devirt 0xFEA00000 (0x100 pages, 0x8000000000000001) skip 0 39:551 00:003 OCABC: MMIO devirt 0xFEC00000 (0x1 pages, 0x8000000000000001) skip 0 39:555 00:003 OCABC: MMIO devirt 0xFEC10000 (0x1 pages, 0x8000000000000001) skip 0 39:558 00:003 OCABC: MMIO devirt 0xFED00000 (0x1 pages, 0x8000000000000001) skip 0 39:562 00:003 OCABC: MMIO devirt 0xFED40000 (0x5 pages, 0x8000000000000001) skip 0 39:566 00:004 OCABC: MMIO devirt 0xFED80000 (0x10 pages, 0x8000000000000001) skip 0 39:570 00:003 OCABC: MMIO devirt 0xFEDC2000 (0xE pages, 0x8000000000000001) skip 0 39:574 00:003 OCABC: MMIO devirt 0xFEDD4000 (0x2 pages, 0x8000000000000001) skip 0 39:578 00:003 OCABC: MMIO devirt 0xFEE00000 (0x100 pages, 0x8000000000000001) skip 0 39:581 00:003 OCABC: MMIO devirt 0xFF000000 (0x1000 pages, 0x8000000000000001) skip 0 39:586 00:004 OCABC: MMIO devirt 0x10000000000 (0x10400 pages, 0x8000000000000001) skip 0 39:589 00:003 OCABC: MMIO devirt 0x3CB90000000 (0x10400 pages, 0x8000000000000001) skip 0 39:593 00:003 OCABC: MMIO devirt 0x3CBC0000000 (0x10400 pages, 0x8000000000000001) skip 0 39:596 00:003 OCABC: MMIO devirt 0x69750000000 (0x10400 pages, 0x8000000000000001) skip 0 39:599 00:003 OCABC: MMIO devirt end, saved 1087664 KB 39:603 00:003 OCABC: Only 176/256 slide values are usable! 39:607 00:003 OCABC: Valid slides - 80-255 As you can see the addresses start the same, but then they diverge. I also backed out a white list from doing the @iGPU booting experiment, which essentially disabled only 2 of them (3rd and 4th from bottom). I booted successfully with 2 enabled all else disabled, then tried to enable the next 2 and failed, then succeeded on 2 enabled, 2 disabled, 1 enabled, all else disabled. Decided to enable all after and booted again successfully as it didn't make sense to have 2 disjoint regions of memory affected reducing the search to 6 reboots. After I added the whitelist I managed to get the same "clicking off" experience on shutdown as @iGPU. Then, I was about to test NVRAM with SSDT and among some other reboots and tweaks, when my entire install got somehow compromised and I could not a find a single EFI (including ones that worked before) where I could stably boot or perform recovery or reinstall. I'd get forced restarts 2 minutes into sessions. Flashed BIOS, as I can't explain how this is possible without board NVRAM corruption, and went back to VMs. MmioWhitelist.plist.zip
  10. My guess is that @iGPU made his repository private and did not delete it. He probably has a reason such as needing to change things and not having the time / not having it figured out yet.
  11. @fabiosun - well, that goes without saying. My only registration on any macOS related forum is here, and I don't speak a word of Italian and had never done any "Hackintosh" before 😉. These public guides add big value though as they are edited and vetted by a larger audience. I am bit suspicious of the TRX40/AMD section though, and still worried to re-try bare metal as I have a very stable VM setup and don't want to end up flashing my BIOS again.
  12. Great catch on this new info. Has anyone tried this guide yet? The MMIO and other sections seems to be motherboard-agnostic. I will give it a shot tonight.
  13. I wouldn't update OC with daily builds without knowing what issue it is addressing. It's just not worth the trouble and time. I will stick with 0.6.0 until the next one is released.
  14. @valmeida - how do you like that Zenith II? Is that your PC hanging off the wall 🙂 ? Nice one.
  15. I noticed this mentioned on GB forums https://www.amazon.com/dp/B08BC11XW8/ref=cm_sw_em_r_mt_dp_GA3pFbDFSJTQD Is Gigabyte ditching the Titan Ridge in favor of an Intel chipset? Name still says TR but lists Intel's brand on the chipset. No USB ports from visual inspection and different chipset (original one didn't have USB either - seems identical visually but different revision) . Given the many problems this card is causing for various people I wonder if they decided to move in a different direction.
  16. Was trying to figure if any custom SSDTs are used by people with Proxmox. Do they help or make a difference with USB speed? @Driftwood - I see that you use MacPro7,1 - assuming you pass your USB controller with PCI. Do you employ any SSDT renames / capability injects?
  17. @iGPU - went over the full write up on your GitHub finally - great job 👍. I noticed you wrote that BIOS could get corrupted. After all my travails the past 2 days I had reached the same conclusion so I re-flashed earlier today. Now I am wondering if I should re-test with emulated NVRAM to prevent NVRAM writes by OC and MacOS? Are OC NVRAM writes avoidable? Another question - I had tried before my stability issues to dump the memmap file for the slide in the EFI via the console (on fs0: as per your instructions) but later on when OC would boot into MacOS that file would be gone from the EFI folder. I could only see it if I am in the openspell itself but then I did not know how to open an editor there. Anything I missed before I retry? Edit: I am also finally catching up on the Proxmox old threads, as for me Proxmox runs rock solid. Wanted to find out what else can I improve i.e. extra USB 3.1 expansion, USB controller speeds etc. I noticed you had a Designare too and abandoned due to instability! Funny, but I am so tired of the quirks of this board that I am close to pulling the same trick, but I am eyeing the Asus Zenith II as there is a discounted open-box one in a store nearby. Trying to sort out with Gigabyte and their BIOS team, will give it 1-2 more weeks. Proxmox is rock solid as well as Ubuntu - the only reason I keep this board (and the free add-ons of course).
  18. @tsongz - yes you can do that. Just set your boot disk to be a small disk image containing the efi with an OC config entry that would be saved in the VM's NVRAM pointing to your OS disk. I boot this way into my Big Sur VM as I find it more likely to change something there due to the beta and frequent updates. For the stable Catalina one I chose to not bother as I found it robust and put EFI on the boot + OS shared disk volumes - that way I can carbon copy clone the entire thing in 1 shot since I don't think the script that does that would work with split-drive EFI and boot volumes. Maybe you can modify the script if you care about cloning both EFI and disk.
  19. @iGPU - it was with npci=0x2000 that I actually got the initial error. I actually had missed the energy saver part, and now that you get my attention to it, I was playing with that part of the BIOS (ErP and wake on LAN) around the time my issues started happening, but I later reverted those changes and that didn't fix it. At this point I am more worried about some hardware or NVRAM corruption on my end than actually getting the bare metal itself. However, I still think it is more likely to turn out that it is a subtle bug in the EFI. I will go over your guide and rebuild the EFI from scratch using the tools recommended (I do use OC configurator latest and I see you recommend doing more XML-native edit tools so I will do that too). Thank you for the writeup.
  20. I have no idea what happened to my hardware and this setup but I can't install this. I can get in the installer with a very barebones config.plist and a minute into it everything freezes. I wonder if my video card is acting up. I am out for now. No idea how to debug this. I tried several EFI's. Only thing I haven't tried is BIOS reflash. I either get a reboot of OC or I get in but then get a freeze. This is very bizzare as I had no problems whatsoever last week.
  21. Yeah I am worried about BIOS corruption. So I stated from scratch. Managed to get into the installer. My mouse and keyboard froze a few times and had to hard reboot but finally going. Ended up going all the way back to the barebones EFI of iGPU from page 2 or 3 of this thread. Edit: the installer froze. I guess my only option is to pin jump CMOS and retry.
  22. I used to have a working EFI and after a few days started experiencing instability where I could not even boot from it anymore. No idea what changed. Has to be BIOS related. So booted but and got into setup screen but now I have no mouse and kbd. Let me see what's going on.
  23. @iGPU - tried the EFI you just checked in GitHub. Stuck on [ PCI configuration begin ]. Edit: Managed to boot after tweaking the boot args (no npci needed for me for some reason) and stripped various kexts
  24. by "safe" I mean the one I installed initially and ran without reboots for a good part of the week. I put in quotations as I know it's not really safe. Will try iGPUs now. If not working I am at a loss on how to debug as this seems to be past the OC handoff.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.