wartości szczytowe kernel_task rMBP podczas podłączania więcej niż jednego monitora zewnętrznego [duplikat]

Po podłączeniu drugiego monitora zewnętrznego kernel_task skacze do 600% +. To sprawia, że ​​komputer nie nadaje się do użytku.

Przed Yosemite działało dobrze z 3 monitorami.

Oto szczegóły:

• Po podłączeniu jednego monitora do DP lub HDMI wszystko działa dobrze.
• Kiedy podłączam drugi monitor z pikami DP lub HDMI kernel_task.
• Kiedy odłączam DP lub HDMI, czasami kernel_task szybko wraca do normalnego poziomu.
• Po odłączeniu wszystkich monitorów kernel_task szybko wraca do normalnych poziomów. (W Goto Monitor aktywności View > Update Frequency > Very Ofteni zaraz po odłączeniu monitorów otrzymasz wiele szybkich aktualizacji interfejsu użytkownika).
• Czasami po podłączeniu dwóch monitorów działa (DP lub HDMI), ale trzeci powoduje natychmiastowy skok. Po tym zdarzeniu wszystkie monitory muszą zostać usunięte, aby powróciły do ​​normy. Czasami usunięcie wszystkiego oprócz jednego to naprawi.
• Czasami, kiedy podłączam wszystkie 3, zajmie to 3 minuty +.

Co próbowałem:

• Resetowanie pamięci NVRAM.
• Resetowanie SMC.
• Próba powyższego scenariusza z podłączonym zasilaczem i działającym na baterii.
• Wyłączanie „automatycznego przełączania grafiki” w trybie oszczędzania energii.
• Korzystanie ze zintegrowanej grafiki za pomocą sudo pmset -c gpuswitch 0

UWAGA: Próbowanie niektórych z tych rzeczy może czasem potrwać 1 minutę.

Konfiguracja systemu:

Używam MacBooka Pro Retina 2.7 Ghz i7 (Macbook10,1 / połowa 2012) z systemem Yosemite 10.10.1.

Mam 3 zewnętrzne monitory (Dell 2415H) z 2 podłączonymi przez Display Port i 1 z HDMI.

Myślę, że problem dotyczy zarządzania energią. Ilekroć mój procesor osiąga 58 stopni, wydaje się, że tak się dzieje. Właśnie zostawiłem podłączone 3 monitory przez ponad 5 minut i tak się nie stało. Ale kiedy zacząłem szukać za pomocą Chrome, stało się to natychmiast.

Wygląda na dobrą naprawę tutaj: http://www.rdoxenham.com/?p=259

Według Rhys Oxenhams :

jądro będzie zapętlało niektóre bardzo proste zadania, np. ustalanie daty, a zatem „pochłanianie” (z najwyższym priorytetem) większości procesorów w celu schłodzenia systemu.

Rozwiązanie, o którym wspomina na swoim blogu, powinno działać na wcześniejszych komputerach Mac. W przypadku komputerów Ivy-Bridge Mac i nieco wcześniej Richard Schwarting znalazł odpowiedni plik do wyłączenia . Instrukcje znajdują się poniżej dla wygody. Próbowałem wielu rzeczy, ale to działa.

1. Wyłącz kext, zmieniając jego nazwę

   cd /System/Library/Extensions/IOPlatformPluginFamily.kext/Contents/Plugins
   sudo mv X86PlatformShim.kext X86PlatformShim.kext.disabled
   

2. Wyczyść pamięć podręczną kext (nie jestem pewien, czy jest to potrzebne)

   sudo touch /System/Library/Extensions/
   

3. Uruchom ponownie

   sudo reboot
   

• Po zainstalowaniu aktualizacji OSX może być konieczne powtórzenie powyższej procedury, jeśli aktualizacje zostały ponownie utworzone kext.

Aktualizacja dla (wysokiej) Sierra:

TL: TR

Zmień nazwę IOPlatformPluginFamily.kext / ACPI_SMC_PlatformPlugin.kext / [MacModelIdentifier] .plist

Krok po kroku:

1. Uruchom wprowadzenie Tryb odzyskiwania (naciśnij CMD + R podczas uruchamiania)
2. Narzędzie> Terminal csrutil disable(Wyłącz ochronę plików systemowych)
3. Uruchom ponownie i zmień nazwę /System/Library/Extensions/IOPlatformPluginFamily.kext/Contents/PlugIns/ACPI_SMC_PlatformPlugin.kext/Contents/Resources/[MacModelIdentifier].plist(Mac> Informacje> Raport systemu> Identyfikator modelu) na bugfix.plist(lub coś innego)
4. Uruchom ponownie i sprawdź, czy kernal_taskproces spadł poniżej 10%
5. Jeśli się powiedzie, uruchom ponownie w trybie odzyskiwania i ponownie włącz ochronę systemu za pomocą csrutil enable

Testowany i pracował dla mnie o 10.13.2 na początku 2011 MacbookPro.

Źródło ze zdjęciami (niemiecki) http://www.couchpiratin.de/mac-zu-langsam-kernel_task-cpu-fehler-beseitigen/