wujek_bogdan

Zacznij od poprawnej konfiguracji portów USB. Utwórz mapę portów, następnie pozbądź się patcha na limit portów oraz kexta UsbInjectAll. Przejrzyj też sekcję Fixing Sleep z poradnika.

Napisz co zrobiłeś, żeby rozwiązać problem. Może komuś się przydać. Zanotuj czas resetu. Po restarcie otwórz /var/log/system.log i sprawdź moment, w którym nastąpił reset. Być może uda się zdebugować problem.

Nie poradzę ci nic więcej poza tym co jest napisane tutaj https://dortania.github.io/OpenCore-Install-Guide/config.plist/haswell.html#deviceproperties i tutaj https://dortania.github.io/OpenCore-Post-Install/universal/drm.html#fixing-drm-support-and-igpu-performance Zacznij oczywiście od upewnienia się, że w BIOS-ie iGPU jest włączona. Nie zdziwiłbym się, gdybyś miał po prostu wyłączoną integrę w BIOS-ie. Nawet jeśli nie jest to przyczyna lagującego UI to i tak wypada mieć włączoną ekcelerację graficzną - bez tego możesz mieć problem np. z niedziałającą aplikacją do podglądu obrazków. Krótko mówiąc: na dobrze zrobionym hacku ma to działać.

Na pewno to nie jest normalne, ale nie spotkałem się z tym nigdy. RX 570/580 powinno po prostu działać od kopa dzięki WhateverGreen. Odnośnie GTX 760 się nie wypowiem. Z tego co widzę, to platform-id masz poprawnie ustawiony (iGPU masz odpalony w trybie headless zgodnie z poradnikiem) Możesz sprawdzić czy rzeczywiście działa ci tryb headless i akceleracja graficzna iGPU https://dortania.github.io/OpenCore-Post-Install/universal/drm.html#fixing-drm-support-and-igpu-performance ale nie sądzę, żeby miało to wpływ na ogólną wydajność. Jeśli się nie mylę to ta akceleracja graficzna dotyczy jedynie pewnych zdań jak np kompresja wideo. Nie zaszkodzi jednak tego sprawdzić w ramach szlifowania konfigu. Mogę się jednak mylić, być może działanie UI jest również wspierane przez iGPU? Nigdy nie drążyłem tematu, ale zawsze też uruchamiałem akcelerację graficzną dla iGPU.

Gdy masz już mapę portów w postaci kexta, to nie potrzebujesz SSDT-UIAC.aml. źródło: https://dortania.github.io/OpenCore-Post-Install/usb/intel-mapping/intel.html

Sprawdź ten wątek: https://hamac.pl/topic/16866-rozwiązany-asus-z87m-plus-niektóre-porty-usb-nie-są-wykrywane/ - rozwiązaniem jest odpowiednie zmapowanie portów. Rozwiązanie jest w tym wpisie, ale przeczytaj cały wątek, dla kontekstu. Też ostatnio walczyłem z portami USB na Z87 i wygląda na to, że masz identyczny problem.

Zacząłbym od poprawienia konfigu. Nie wygląda jakbyś podążał za poradnikiem: https://dortania.github.io/OpenCore-Install-Guide/config.plist/haswell.html Pierwsza rzecz, która się rzuca w oczy to nadmiarowe patche ACPI. Gdybyś stawiał system zgodnie z poradnikiem miałbyś tam tylko SSDT-EC-USBX-DESKTOP.aml oraz SSDT-PLUG-DRTNIA.aml. Najbardziej podejrzany jest DSDT.aml - to kompletny zrzut DSDT. Nie powinieneś go używać. Być może miałeś jakiś powód, dla którego załadowałeś dodatkowe patche, ale jeśli tak jest to napisz coś więcej o problemach jakie miałeś przy instalacji i jak próbowałeś je rozwiązać. Kolejna sprawa to kexty - jest kilka, które wydają się niepotrzebne: FakePCIID oraz FakePCIID_XHCIMux - jaki problem próbowałeś rozwiązać za ich pomocą? Ostatnia rzecz (a być może pierwsza ;)) to fakt, że plik BOOTx64.efi ma datę ze stycznia. Wygląda więc na to, że używasz starej wersji OpenCore. Zakładam, że jest to wersja styczniowa, czyli 0.6.5. Sprawdziłem twój konfig validatorem i jest w nim kilka błędów: m.in. w sekcji UEFI/Output oraz UEFI/ProtocolOverrides się nie zgadza. Ale tutaj mogę się mylić, bo być może nie używasz wersji 0.6.5, jak założyłem. Najlepiej by było gdybyś konfig sprawdził narzędziem ocvalidate - znajdziesz je w katalogu /Utilities/ocvalidate/ gdy rozpakujesz paczkę z OpenCore. Ważne, żeby używać narzędzia zgodną z używaną wersją OpenCore. Jeśli chodzi o log, to wrzuć go proszę w lepszej rozdzielczości bo na załączonym zdjęciu niewiele widać - OpenCore potrafi zapisywać logi do pliku, gdy włączysz tryb debugowania.

Dzięki, za linka - oszczędziłeś mi szukania. Dla potomnych: https://dortania.github.io/Wireless-Buyers-Guide/unsupported.html#supported-chipsets - warto pamiętać, że nie każdy natywnie występujący w Makach chipset będzie działać w najnowszych wersjach systemu. Nowsze wersje systemu porzucają wsparcie dla starszych chipsetów.

No właśnie, na Aliexpress, w dobrej cenie można kupić kartę już z adapterem na pci-e, ale podejrzewam, że lepiej kupować używki wyciągnięte z maków niż nówki niewiadomego pochodzenia.

Chcę do hacka podłączać słuchawki bezprzewodowe. Wiem, że mogę kupić dongla na USB, ale mam obawy czy będzie to działać dobrze. Nie chcę za każdym razem mordować się z parowaniem urządzenia, więc sądzę, że natywne rozwiązanie będzie lepsze. Widzę, że popularnym (a może jedynym?) rozwiązaniem jest BCM94360CS2 lub BCM94331CD . Czy ta karta + adapter na PCI-E to pewne rozwiązanie? Czy każde słuchawki bluetooth będą działać?

Dokumentacja mówi, że 04001204 to ig-platform-id dla Haswella. Dla Broadwella to 07002216 (czyli BwAiFg== w base64). Nie mówi natomiast czy to id dla normalnego trybu, czy trybu headless, obawiam, się, że dla normalnego trybu. Zapytałbym na Githubie, albo na Insanelymac, może tam znajdzie się ktoś kto wie jakiego ig-platform-id użyć. // Edycja Tutaj masz listę wszystkich obsługiwanych przez WhateverGreen ig-platform-id https://github.com/acidanthera/WhateverGreen/blob/master/Manual/FAQ.IntelHD.en.md#intel-hd-graphics-5300-6300-broadwell-processors Musiałbyś je przetestować metodą prób i błędów. Mała uwaga: W ten sposób otrzymujesz wartość zapisaną w systemie szesnastkowym, który następnie, gdy edytujesz konfig, musisz przekonwertować do base64. W podanym przykładzie, dla wynikowej wartości 3A1E0000 będzie to string Oh4AAA== hexy do base64 przekonwertujesz sobie np tutaj: https://base64.guru/converter/encode/hex

Udało się, trochę na około ale się udało. Zauważyłem taką prawidłowość: Mając XhciPortLimit na false działały wszystkie porty USB 2.0 i tylko niektóre porty USB 3.0 Mając XhciPortLimit na true działały wszystkie porty USB 3.0 i tylko niektóre porty USB 2.0 Korzystając z tego, ustawiłem XhciPortLimit na true i zmapowałem porty USB 3.0, następnie zmieniłem XhciPortLimit na false, zrestartowałem system zmapowałem wszystkie porty USB 2.0, po czym wygenerowałem USBMap.kext, usunąłem USBInjectAll.kext oraz zostawiłem XhciPortLimit na false. Teraz wszystko działa. Mam zmapowane wszystkie 14 portów. Pod EH01 nie było żadnych urządzeń więc USBMap zaproponował mi wyłączenie tego urządzenia, co z resztą mogłem zrobić już wcześniej za pomocą SSDT-EHCx_OFF.aml - nie robiłem tego w obawie, że to właśnie ten patch powodował, że porty nie są wykrywane - myliłem się.

Możesz ustawić opcję HideAuxiliary na true: https://dortania.github.io/docs/latest/Configuration.html#x1-44006x3 wtedy ukryte zostaną wszystkie niebootowalne partycje, partycje recovery, Time Machine, etc. Nie wiem czy da się konfigurować ręcznie opcje bootloadera. Czytając, z grubsza, dokumentację nic takiego nie znalazłem.

Miałem ten fix ACPI ale już nie mam. On, jeśli się nie mylę, zupełnie ubija urządzenie. Usunąłem go, bo podejrzewałem, że to on jest odpowiedzialny za niedziałające porty, ale myliłem się - z nim, czy bez niego problem jest ten sam.

Tak - tak jak pisałem w pierwszym wpisie, z płytą jest wszystko OK. Port działa pod Windows, mogę też z tego portu (a w zasadzie portów, bo 4 nie działają), zbootować OpenCore, więc na etapie bootloadera wszystko jest OK. Porty nie działają tylko po załadowaniu systemu. Możliwe, że coś jest na rzeczy, bo widzę podobne wpisy w sieci, np. ten: https://www.reddit.com/r/hackintosh/comments/mzurrz/after_updating_to_113_usb_20_devices_dont_work_in/ Sprawdzę, dla testu, czy przestawienie XhciPortLimit na false rozwiąże problem. Wiem, że to nie ma sensu, ale być może jest jakiś błąd w OC?

Wydaje mi się, że źle zrozumiałeś mój wpis. Używam USBMap (screen, który wrzuciłem wyżej pochodzi właśnie z USBMap). Problem jest nie w samym mapowaniu portów - ten proces jest dla mnie jasny, tylko w tym, że w przypadku niektórych portów ani USBMap ani Hackintool nie rozpoznaje, że zostało do niego wetknięte urządzenie USB 2.0. Nie mogę ich więc zmapować. Urządzenie nie pojawia w takim przypadku również w Finderze. Na drugim hacku, gdzie z mapowaniem nie było żadnych problemów, po zmapowaniu pozbyłem się USBInjectAll, zastąpiłem go wygenerowanym kextem USBMap.kext i usunąłem patch na limit portów w OpenCore. Takie rozwiązanie wydaje mi się najbardziej eleganckie.

Przyszedł czas na aktualizację do BigSur, postanowiłem więc przy okazji przesiąść się na OpenCore i w końcu pozbyć się USBInjectAll i po bożemu zastąpić go mapą portów USB. Zrobiłem więc wszystko co należy zrobić wcześniej, zgodnie z System Preparation z poradnika Dortania. Dodałem patch ACPI podmieniający EHC1 na EH01 Zainstalowałem UsbInjectAll Włączyłem w OpenCore XhciPortLimit USBMap nie pokazuje żadnych błędów. Ale mam problemy z mapowaniem portów: Wszystkie porty USB 3.0 są wykrywane poprawnie Cześć portów USB 2.0 jest wykrywania poprawnie Część portów USB 2.0 w ogóle nie reaguje. Nie pojawiają się ani w USBMap, ani w Hackintool ani w Finderze. Z płytą główną wszystko jest OK. Pod Windowsem te porty działają poprawnie, mogę nawet zbootować z nich OpenCore czy Clovera, ale urządzenia "znikają" gdy system już się uruchomi. Mój konfig OC 0.6.9 config.plist

Powstał fork OpenCore, który pozwala na wyłączenie patchowania ACPI dla WIndows. Niestety projekt zatrzymał się na OpenCore 0.5.8 i nie jest już aktualizowany.

Ups. Dzięki za sprostowanie.

Postawisz. Widzę, że na Githubie można znaleźć gotowe konfigi dla x79 dla Clovera. Jeśli chcesz stawiać system za pomocą OpenCore, to tutaj masz ogólny poradnik dla Ivy Bridge. Z kartą graficzną nie będzie problemów.

To właśnie dobry powód do przesiadki na OpenCore. Na nowym hacku na z490 używam OpenCore, na starym, na z87 nadal jest Clover oparty na forumowym UnibootX, ale aktualizując do Big Sur planuję przesiadkę na OpenCore.

Przykro mi ale nic więcej chyba nie jestem w stanie pomóc. Nie mam doświadczenia z AMD. Obawiam się, że jedyna droga to szukanie pomocy na https://www.insanelymac.com/

Na samym dole masz komunikat błędu: "virtualsmc no extra rtc memory" - szukając w google natknąłem się na wpis, który mówi, że poprawka SSDT-EC rozwiązała problem. Ale to tylko strzał - nic mi ten komunikat nie mówi. Jeśli ta poprawka nie pomoże, to pisałbym na https://www.insanelymac.com/ - tam siedzą m.in. programiści OpenCore. Ewentualnie sprawdziłbym jeszcze https://github.com/acidanthera/RTCMemoryFixup - ale to zupełny strzał, nie poparty żadną wiedzą. Pamiętaj, że w OpenCore instalując kexta nie wystarczy go wrzucić do katalogu - musisz dodać też wpis do konfigu.

Wrzuciłem twój konfig w walidator i widzę, że brakuje patchów dla Kernela. Najprawdopodobniej to jest przyczyną problemu. Kolejna rzecz, którą znalazłem (choć nie sądzę, żeby była związana z twoim problemem) to SSDT-EC-USBX. W konfigu figuruje pod nazwą SSDT-EC-USBX.aml natomiast a katalogu ACPI plik nazwany jest SSDT-EC-USBX-DESKTOP.aml. Zmień nazwę tak aby wpis w konfigu był zgodny z nazwą pliku na dysku. Następna rzecz to kext AppleMCEReporterDisabler - widnieje w konfigu, nie masz go natomiast na dysku. Nie wiem co robi ten kext, to chyba coś specyficznego dla AMD. Doczytaj co to jest i albo dodaj ten kext albo usuń z konfigu. Nie możesz w pełni polegać na walidatorze, on sprawdza tylko konfig - nie ma dostępu do twojego EFI, a więc nie wszystko co się świeci na zielono jest na 100% OK. Upewnij się też, że BIOS ustawiłeś zgodnie z poradnikiem.

W jaki sposób przygotowałeś konfig? Korzystałeś z Dortania's OpenCore Install Guide? Jeśli nie to spróbuj przygotować konfig wg tego poradnika. Nic lepszego w sieci nie znajdziesz. Czy po przygotowaniu konfigu sprawdzałeś go za pomocą walidatora https://opencore.slowgeek.com/ ? Problem wygląda mi na coś związanego z alokacją pamięci, ale ciężko powiedzieć co dokładnie. Może to być kwestia źle spatchowanego kernela (albo nie spatchowanego?), może to być kwestia ustawień BIOS-u. Ciężko mi powiedzieć coś więcej bo mam zerowe doświadczenie z macOS na AMD.