rMBP kernel_task шипів при підключенні більше ніж один зовнішній монітор [дублікат]

Під час підключення другого зовнішнього монітора kernel_task шипає до 600% +. Це робить комп'ютер непридатним.

До Йосеміті це спрацювало чудово з 3 моніторами.

Ось специфіка:

• Коли я підключаю один монітор до DP або HDMI, все працює нормально.
• Коли я підключаю другий монітор з шипами DP або HDMI kernel_task.
• Коли я відключаю або DP, або HDMI, іноді kernel_task швидко повертається до нормального рівня.
• Коли я відключаю всі монітори, kernel_task швидко повертається до нормального рівня. (У програмі «Монітор активності» перейдіть, View > Update Frequency > Very Oftenі як тільки ви відключите монітори, ви отримаєте безліч швидких оновлень інтерфейсу користувача).
• Іноді при підключенні двох моніторів він працює (DP або HDMI), але третій викликає негайний сплеск. Після цього всі монітори повинні бути зняті, щоб він повернувся до нормального стану. Іноді видалення всіх, крім одного, це виправить.
• Іноді, коли я підключаю всі 3, для цього потрібно 3 хвилини +

Що я спробував:

• Скидання NVRAM.
• Скидання SMC.
• Спроба вищезазначеного сценарію з підключеним і працює батареєю адаптер живлення.
• Вимкнення "Автоматичної графічної комутації" в енергозбереженні.
• Використання інтегрованої графіки за допомогою sudo pmset -c gpuswitch 0

ПРИМІТКА. Для спроби деяких з цих випадків іноді потрібно 1 хвилина.

Конфігурація системи:

Я запускаю MacBook Pro Retina 2.7 ГГц i7 (Macbook10,1 / середина 2012 року) під керуванням Yosemite 10.10.1.

У мене є 3 зовнішніх монітора (Dell 2415H) з 2 підключеними дисплеєм і 1 з HDMI.

Я думаю, що це стосується управління енергією. Щоразу, коли мій процесор потрапляє на 58 градусів, це, здається, трапляється. Я просто залишив мої 3 монітори, підключені до 5+ хвилин, і це не сталося. Але коли я почав пошук за допомогою Chrome, це негайно сталося.

Тут добре виглядає виправлення: http://www.rdoxenham.com/?p=259

За словами Ріса Оксенхама :

ядро буде продовжувати циклічно виконувати деякі дуже прості завдання, наприклад, отримати дату, тому «споживаючи» (з найвищим пріоритетом) більшість ЦП, намагаючись охолодити систему.

Рішення, яке він згадує у своєму блозі, має працювати для більш ранніх Macs. Для Mavy-Bridge Macs та трохи раніше Річард Швартінг знайшов відповідний файл для відключення . Нижче наведено інструкції для зручності. Я спробував багато речей, але це працює.

1. Вимкніть кекс, перейменувавши його

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

2. Очистити кеш-кеш (не впевнений, чи це потрібно)

   sudo touch /System/Library/Extensions/
   

3. Перезапустити

   sudo reboot
   

• Після установки оновлень для OSX вам може знадобитися повторити вищевказану процедуру, якщо оновлення заново створили kext.

Оновлення для (Висока) Сьєрра:

TL: TR

Перейменуйте IOPlatformPluginFamily.kext / ACPI_SMC_PlatformPlugin.kext / [MacModelIdentifier] .plist

Крок за кроком:

1. Запустіть режим відновлення введення (під час запуску натисніть CMD + R)
2. Утиліта> Термінал csrutil disable(вимкнути захист системних файлів)
3. Перезавантажте та перейменуйте /System/Library/Extensions/IOPlatformPluginFamily.kext/Contents/PlugIns/ACPI_SMC_PlatformPlugin.kext/Contents/Resources/[MacModelIdentifier].plist(Mac> Про систему> Звіт> Ідентифікатор моделі) на bugfix.plist(або щось інше)
4. Перезапустіть і перевірте, чи kernal_taskпроцес знижується нижче 10%
5. У разі успішного перезапуску знову в режимі відновлення та ввімкніть системну протекцію знову за допомогою csrutil enable

Тестував і працював для мене о 10.13.2 на початку 2011 року MacbookPro.

Джерело із зображеннями (німецькою) http://www.couchpiratin.de/mac-zu-langsam-kernel_task-cpu-fehler-beseitigen/