Jump to content

wujek_bogdan

Members
  • Content Count

    932
  • Joined

  • Last visited

  • Days Won

    8

Everything posted by wujek_bogdan

  1. Ten problem został rozwiązany. Pomaga Lilu + WhateverGreen. Ale najlepiej niech się wypowie posiadacz Radeona. Na kartach Nvidia też pojawia się problem z wybudzeniem, tutaj również pomaga Lilu + WhateverGreen, ale rozwiązanie ma swoje wady. Więcej tutaj: http://hamac.pl/topic/15154-problemy-ze-sleep-po-aktualizacja-sierra-do-high-sierra/ Co mas na muśli mówiąc patcher?
  2. Kupowałem od nich ostatnio na Allegro. Większość płyt to niestety wersje OEM, bez maskownicy portów.
  3. Zaktualizowałeś też Lilu? Odwrotnie W nowym WhateverGreen działa tylko agdpmod (patrzyłem nawet w kod źródłowy żeby to potwierdzić), ale autor WhateverGreen twierdzi, że problem, z którym mamy do czynienia to wina sterowników Nvidia i występuje też na prawdziwych makach. Zgłosiłem już ten błąd do Nvidia, może zostanie naprawiony. Twierdzi też, że agdpmod=pikera nie powinien być używany i należy próbować różnych wartości dla parametru darkwake. Nie wyjaśnia jednak dlaczego. źródło tej informacji: https://github.com/acidanthera/bugtracker/issues/282 Ja i tak nadal używam agdpmod=pikera, ponieważ nie znalazłem innego rozwiązania, które by u mnie działało. Nie testowałem jeszcze różnych wartości dla darkwake ponieważ nie znalazłem żadnego sensownego opisu co poszczególne wartości dla darkwake oznaczają. Jak będę miał czas to się tym pobawię. U mnie ten problem nie występuje, ale być może u ciebie problem jest związany z tym, że używasz 2 monitorów. Spróbuj zgłosić ten problem na githubie: ​https://github.com/acidanthera/bugtracker Być może warto napisać o tym też na insanelymac. Udziela się tam autor WhateverGreen. Warto spojrzeć w /var/log/system.log. Być może znajdziesz tam jakieś komunikaty, po których uda się dojść do przyczyny problemu. Ehh... Ja jakiś czas temu zmieniłem Radeona R9 280x na Nvidię, bo wtedy podobne problemy występowały na Radeonach. Dopiero WhateverGreen rozwiązałe ten problem. Szkoda, że się wtedy nie wstrzymałem z wymianą.
  4. Nie jestem pewien czy rozumiem pytatanie. Chodzi ci o to, że chcesz mieć pewność, że bootujesz z pendrajwa, a nie z partycji EFI dysku systemowego? Jeśli tak to nie musisz nic usuwać z partycji EFI żeby bootować z pendrajwa - kolejność bootowania jest zależna tylko od ustawień w BIOS-ie. Ale dla pewności możesz usunąć/zmienić nazwę katalogu EFI/CLOVER na partycji EFI. Jest też taka opcja, że wprowadziłem cię w błąd. Być może Clover zapisuje nvram.plist na partycji EFI dysku systemowego nawet gdy bootujesz z pendrajwa. Byłoby to dziwne, ale nie wykluczam takiej opcji. Jeśli chodzi o zapis do nvram to polecam ten wątek: http://hamac.pl/topic/9672-natywny-zapis-warto%C5%9Bci-do-nvram/
  5. W takim razie wygląda na to, że wcale nie bootujesz z pendrajwa, tylko nadal bootujesz z partycji EFI. Upewnij się, że bootujesz z odpowiedniego bootloadera (np. zmień theme w ustawieniach ).
  6. To co napisałem wyżej to tylko moje wnioski na podstawie wpisu RehabMan, nie są poparte żadną wiedzą, więc nie jest wykluczone, że to Ty masz rację. Warto to sprawdzić. Z chęcią to przetestuję, muszę tylko się zaopatrzyć w adapter USB wpinany do płyty, bo inaczej nie przetestuję wszystkich portów, a jedynie 6 portów, które wychodzą z płyty głównej + 2 porty USB 3.0, które mam na front panelu, czyli razem tylko 8 portów. Odświeżę temat gdy będę miał czym testować.
  7. Właśnie w tym rzecz, że nie jest potrzebny. Patch jest potrzebny jest tylko do przygotowania SSDT, ale po zaaplikowaniu SSDT patch na limit portów można (a nawet trzeba) usunąć. Cytat z poradnika RehabMana:
  8. Myślę że warto się tym pobawić. RehabMan przygotował poradnik orasz szablon SSDT, za pomocą którego można przygotować własne SSDT. IMO to bardzo eleganckie rozwiązanie ponieważ po zastosowaniu własnego SSDT nie są konieczne patche w Cloverze, które zależne są od wersji macOS. W wolnym czasie pobawię się tym i zaktualizuję temat.
  9. Niestety nie jestem w stanie nic więcej pomóc, musi się wypowiedzieć ktoś z większym doświadczeniem.
  10. Tak, chodziło mi o to żebyś pobrał UnibootX i wyciągnął z niego konfig. Nie ma tam co prawda dedykowanego konfigu dla twojego chipsetu płyty głównej, więc wziąłbym ten najbliższy twojemu czyli konfig dla Skylake Z170. Jeśli chodzi o zmianę bootloadera - to zmieniając bootloader nie musisz stawiać systemu od nowa. Bootloader możesz mieć nawet na pendrajwie. Ale podejrzewam, że masz go po prostu na osobnej partycji EFI. Tak czy inaczej nie musisz zmieniać bootloadera, bo już używasz Clovera . Nie wiem tylko jakiej wersji używasz, więc skoro zastosujesz konfig z UnibootX, to polecam sprawdzić jakiej wersji Clovera używasz i ewentualnie zaktualizować go żeby mieć pewność że konfig jest kompatybilny - aktualizacja polega na zwykłej podmianie plików w katalogu EFI (partycję EFI możesz zamontować z terminala, albo za pomocą graficznego narzędzia - Clover Configurator). Jeśli nie chcesz mieszać w obecnej konfiguracji to polecam ci przygotować pendrive z UnibootX i z niego startować system. Gdy uda ci się odpalić system, który działa jak należy to wtedy przerzucisz sobie Clovera z nowym konfigiem na partycję EFI na twardym dysku. Nie chcę się za bardzo rozpisywać na ten temat, bo informacje na temat UnibootX Clover znajdziesz tu: http://hamac.pl/topic/11716-unibootx-clover-oficjalny-uniwersalny-bootloader-hamacpl/ http://hamac.pl/topic/11724-unibootx-clover-jak-poprawnie-przygotowa%C4%87-konfiguracj%C4%99/ Jeśli chodzi o dostosowanie konfigu, to na początek dodaj tylko następujące rzeczy: W sekcji SystemParameters ustaw NvidiaWeb na true, czyli: <key>SystemParameters</key> <dict> <key>InjectKexts</key> <string>Yes</string> <key>NvidiaWeb</key> <true/> </dict> W sekcj Graphics wszystkie opcje na false, czyli: <key>Graphics</key> <dict> <key>Inject</key> <dict> <key>ATI</key> <false/> <key>Intel</key> <false/> <key>NVidia</key> <false/> </dict> </dict> --- Jest jeszcze jedna rzecz, o której nie było mowy w tym temacie. Czy system jest czysty? Czy nadpisywałeś jakieś kexty systemowe w System/Library/Extensions albo /Library/Extensions (świadomie, albo za pomocą narzędzi jak MultiBeast)? Jeśli tak to wtedy polecam przeinstalować system i zacząć od nowa... chyba, że wiesz co modyfikowałeś i jesteś w stanie przywrócić oryginały.
  11. Patrzę, tak z grubsza na twój konfig Clovera i widzę, że panuje tam spory chaos. Masz tam m.in. mnóstwo fixów DSDT - czy wszystkie są potrzebne? Kolejna rzecz, na którą zwróciłem uwagę to true Inject -> ATI ustawione na <true>. To jest zupełnie zbędnne (ale z drugiej strony, nie wiem czy może powodować problemy). Tak czy inaczej w konfigu konfig powinien być ograniczony do minimum. Każda dodatkowa rzecz to potencjalny problem. Na twoim miejscu spróbowałbym uruchomić system na konfigu Clovera wyciągniętym z UnibootX. Jeśli tam grafika zaskoczy, to dopiero wtedy szlifowałbym konfig Clovera. // Edit: Możesz pobawić się dodatkowymi flagami boot args w NvidiaGraphicsFixup (obecnie zintegrowanym z WhateverGreen)
  12. @Konrado0905 dzięki za ngfxpatch=pikera - u mnie również rozwiązuje problem z budzeniem się monitora. Problem z brakiem 4k na ekranie logowania, o którym piszesz, rozwiązuje WhateverGreen v1.2.0. BTW, od tej wersji NvidiaGraphicsFixup nie jest już potrzebny, został włączony do WhateverGreen. // edit: W WhateverGreen zmieniono nazwę flagi ngfxpatch=pikera na agdpmod=pikera
  13. Możesz jeszcze spróbować skryptu instalacyjnego: http://hamac.pl/topic/15213-skrypt-do-instalacji-sterownik%C3%B3w-od-nvidia/
  14. Shiki, IntelGraphicsFixup oraz NvidiaGraphicsFixup wchodzą teraz w skład WhateverGreen. Można je usunąć z listy.
  15. Problem z wydajnością w 4K został naprawiony w NvidiaGraphicsFixup 1.25 (obecnie WhateverGreen). Warto dodać, że w 10.13.6 pojawił się problem z czarnym ekranem po sleep, ale ten rozwiązuje dodanie ngfxpatch=pikera do boot args. // Edit: "Problem" z brakiem rozdzielczości 4K na ekranie logowania rozwiązała aktualizacja WhateverGreen do 1.2.0
  16. NvidiaGraphicsFixup nie jest już potrzebny. Od wczoraj ​NvidiaGraphicsFixup jest częścią WhateverGreen. Można go więc usunąć w przyszłych wydaniach UnibootX Clover. // edit: IntelGraphicsFixup też.
  17. Pytam z czystej ciekawości, bo widzę, że ten temat w ogóle nie jest poruszany na forum, a wydaje się być dość ciekawy a co najważniejsze może być przyczyną jednej z największych bolączek hackintosha - czyli zarządzania energią. Zainteresowałem się tym ponieważ sam autor twierdzi że nie powinno się używać tego kexta na stałe, a jedynie w celu przygotowania dedykowanego rozwiązania dla posiadanej płyty głównej. U mnie na przykład wszystkie porty USB działają bez customowych łatek. Nie używam ani USBInjectAll ani patcha w Cloverze na limit portów. Abstrajując od tematu. Czy to nie jest tak, że na naszym forum płyty Asusa są tak popularne, bo wyżej wymieniony problem na nich nie występuje? Niewiele wiem na ten temat, ale intuicja mi podpowiada, że problematyczność np. Gigabajtów może być powiązana właśnie z USB. Mam rację?
  18. Wyjąłem grafikę, zainstalowałem IntelGraphicsFixup, włączyłem inject dla intela. Sleep działa, wybudzanie działa (zarówno przyciskiem jak i klawiaturą/myszą). Z tym, że od momentu kliknięcia w "uśpij" do momentu gdy komputer rzeczywiście się uśpi mija czasem nawe 1 minuta (monitor gaśnie od razu). Zroniłem też drugi test. Uruchomiłem iGPU nie wyciągając GTX960 ze slotu. W takiej konfiguracji problem z wybudzaniem nadal występuje. Czy jest jakieś rozwiązanie poza downgrade do 10.12.x ? // EDIT: Znalazłem podobny problem na forum: http://hamac.pl/topic/15154-problemy-ze-sleep-po-aktualizacja-sierra-do-high-sierra/?p=135782 U mnie również pomogło dodanie do boot args flagi: ngfxpatch=pikera Nadal pozostają 2 problemy: - Usypianie trwa moim zdaniem zbyt długo. Nie wiem czy to na 100% jest problem, może to normalne na maku? - Dziwne rzeczy dzieją się z rozdzielczością. Podczas bootowania mam 4k, ekran logowania mam w 1080p, po zalogowaniu mam znowu 4k. Przed zastosowaniem ngfxpatch=pikera cały czas, od ekrany bootowania miałem 4k. --- Nie oznaczam jeszcze postu jako rozwiązany zanim nie przetestuję autosleep. Na razie testowałem tylko ręczne usypianie.
  19. Sprawdzę. Też miałeś restarty podczas spania? Właśnie coś takiego mi się przydażyło. Log z ostatnich minut przed restartem: https://pastebin.com/DGqgVPns pmset -g Currently in use: standby 1 Sleep On Power Button 1 womp 1 autorestart 0 hibernatefile /var/vm/sleepimage powernap 0 networkoversleep 0 disksleep 10 sleep 5 autopoweroffdelay 28800 hibernatemode 0 autopoweroff 1 ttyskeepawake 1 displaysleep 5 standbydelay 10800 Ostatni komunikat wydaje się być związany z tym problemem: assertion failed: 17G65: systemstats + 914800 [D1E75C38-62CE-3D77-9ED3-5F6D38EF0676]: 0x40
  20. System postawiłem na najnowszym UnibootX (2018-07-18). Płyta główna to Asus Z87M-PLUS, grafika to MSI GTX960. Monitor podłączony przez DP. Użyłem konfigu dla Z87. To mój obecny konfig: https://pastebin.com/qFrJWURc Lista kextów: AppleALC.kext FakeSMC_GPUSensors.kext NvidiaGraphicsFixup.kext WhateverGreen.kext FakeSMC.kext FakeSMC_LPCSensors.kext RealtekRTL8111.kext FakeSMC_CPUSensors.kext Lilu.kext SATA_Legacy.kext Komputer usypia się poprawnie, ale po wybudzeniu z uśpienia mam czarny ekran. System się budzi, ponieważ słyszę, że budzą się dyski, szumią wiatraki i dioda zasilania przestaje migać, ale grafika nie wstaje. Wyjęcie i włożenie wtyczki DP nie pomaga. Nie ma znaczenia czy wybudzam komputer przyciskiem czy myszą/klawiaturą. Na razie jedyne rzeczy jakie próbowałem to: Usunięcie USBInjectAll oraz patcha na limit portów z konfigu Clovera Przestawienie w BIOS-ie grafiki z Auto na PCI-E Aktualizacje Nvidia web drivers. Reset ustawień zarządzania energią w preferencjach systemowych
  21. Właśnie ten wątek skłonił mnie do drążenia tego tematu I właśnie o tym patchu wspomina autor USBInjectAll w tekście, który cytowałem w moim poprzednim poście. Mowa o tym fragmencie (wytłuściłem najistotniejsze rzeczy): Ale to tylko teoria. Rozumiem, że autor USBInjectAll, profilaktycznie przestrzega, że USBInjectAll + patch zwiększający limit nie jest uniwersalnym rozwiązaniem. Przejdśmy jednak do praktyki. Uważasz, że w praktyce, jeśli nie ma żadnych widocznych problemów, to tworzenie własnego SSDT to czysta kosmetyka?
  22. @oswaldini Zdaję sobie z tego sprawę. Myślę więc, że warto dodać tę informację do poradnika, szczególnie, że nie jest to rzecz o której się mówi na forum.
  23. 8GB to minimum. Do komfortowej pracy fajnie jest mieć 16GB (szczególnie jeśli będziesz odpalał jakieś wirtualne maszyny, albo, jeśli zajmujesz się webdev - odpalał Photoshopa). Ale ramu zawsze można dołożyć.
  24. Przeglądam konfiguracje dostępne w UnibootX i widzę, że w prawie każdej znajduje się kext: USBInjectAll.kext. Byłem ciekaw co ten kext właściwie robi, zajrzałem na Github: https://github.com/RehabMan/OS-X-USB-Inject-All Zainteresował mnie ten fragment w readme: Z opisu wynika więc że ten kext nie powinien być używany cały czas. Powinien być użyty jedynie do wykrycia portów, które mają być wstrzyknięte. Następnie należy wygenerować SSDT i pozbyć się kexta albo dostosować konfig (rozumiem, że chodzi o edycję pliku USBInjectAll-Info.plist ?). W innym wypadku kext wstrzykuje wszystkie porty. Ciekawe, że ani tutaj ani na InsanelyMac nikt o tym nie pisze. Znalazłem za to wątek napisany przez RehabMan na tonymacx86 Tam znajdziemy następującą informację: --- Zaznaczam, że moja wiedza jest tutaj znikoma. Powtarzam w zasadzie tylko to co na temat kexta pisze autor. Najbardziej interesujący wydaje się być ostatnio cytowany fragment, w którum autor wpomina, że niepoprawne odpalenie USB może mieć wpływ na zarządzanie zasilaniem - co jest bolączką wielu płyt głównych.
  25. Znalazłem całkiem pokaźną i aktualizowanę listę łatek dla Clovera: https://github.com/athlonreg/Common-patches-for-hackintosh Bezpośredni link do źródła: https://raw.githubusercontent.com/athlonreg/Common-patches-for-hackintosh/master/config_patches.plist Szkoda, że ich opisy są bardzo zdawkowe, ale myślę, że i tak warto przykleić ten temat.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.