Panic cpu 2 caller mac os

Решение проблемы перезагрузки Macbook Pro mid 2010 с ошибкой (Kernel Report) по графике

Среди Макбуков середины 2010 года распространена проблема спонтанной перезагрузки с ошибкой по дискретной графике nVidea. Эта проблема не обошла стороной и мой MacBook. Все началось с небольшой ряби при работе в Хроме, переросло в перезагрузки которые прогрессировали. Под конец это происходило несколько раз в день. Но и это, как я знаю — не предел. Внизу текста под катом я привел Panic Report с моего мака.
Я долго искал решение, но если отбросить все полумеры и танцы с бубном с неясным результатом, то все сводилось к перепайке чипа.

Официальное решение от Эпл — замена материнской платы по гарантии или перепайка чипа. Но гарантия давно закончилась, как в прочем и поддержка данной модели производителем. Неофициальные сервисы так же решают вопрос перепайкой чипа.
По отзывам, после таких решений в большинстве случаев проблема рано или поздно возвращается. Я уже искал куда отдать мак на замену чипа, как вдруг наткнулся на другое решение, появившееся на англоязычных форумах.
Кто-то раскопал, что во всем виноват всего лишь один конденсатор! Один из описываемых вариантов решения компромиссный, но без вмешательства в железо, ~~его я описывать не буду, при желании можете сами изучить вопрос.~~
UPD: В комментариях dustwashere сделал перевод второго способа решения проблемы приведенного на том же форуме. Этот способ тоже работает, но при этом несколько режется скорость работы видеокарты, за-то не надо ничего паять. Можно пойти этим путем, если вас не слишком волнует падение производительности видеочипа или нет возможности заменить кондер. Так же dustwashere предлагеает использовать этот вариант для проверки, поможет ли вам замена кондера.
UPD2: Важная поправка от zanami «Там же на макруморсе пишут, что «софтовый» метод не годится, если вы работаете с внешним монитором.»
UPD3: Тут y_skyro_y померил на сколько падает производительность с применением второго «софтового» способа. Вторым предложеным решением я воспользовался и мак снова заработал как раньше!
Это, как я уже сказал, замена одного конденсатора. Ниже на картинке указано, какой кондер нужно заменить. Меняют на аналогичный по параметрам — 330мкФ 2,0 — 2,5В ( 330uF 2.0v non-tantalum poly-film capacitor ). Так же сделан акцент на том, что заменить нужно на НЕтанталовый конденсатор. Я понятия не имею что это значит))
Есть нюанс — кондеры на замену, часто больше по размеру, чем оригинальный, поэтому приходится счищать с платы защитынй слой, увеличивая контактную площадку.
На форуме, пишут, что кондер либо заказывают, либо берут донорский, например с прошки 2012гв.
Знакомый, которого я попросил перепаять кондер, нашел его в своих запасах. Операция не заняла много времени. Думаю, в сервис-центах это обойдется не очень дорого.

Ну вот и все! Ниже картинка с указанием детали под замену, а так же видео, где показана операция замены, а автор много говорит на английском )) Спасибо за внимание, рад если кому-то поможет.
Ну и. я, конечно, ни за что не отвечаю и всё, что вы делаете, вы делаете на свой страх и риск 🙂 PS. Знаю что похожая проблема существует и на прошках других годов выпуска, но я не знаю, имеет ли она схожие причины. [ Мой Panic Report ]
*** Panic Report ***
panic(cpu 2 caller 0xffffff7f90e8ebd5): «GPU Panic: [ ] 3 3 7f 0 0 0 0 3 : NVRM[0/1:0:0]: Read Error 0x00000100: CFG 0xffffffff 0xffffffff 0xffffffff, BAR0 0xd2000000 0xffffff912acbc000 0x0a5480a2, D0, P2/4\n»@/Library/Caches/com.apple.xbs/So urces/AppleGraphicsControl/AppleGraphics Control-3.12.8/src/AppleMuxControl/kext/G PUPanic.cpp:127
Backtrace (CPU 2), Frame : Return Address
0xffffff811858b0a0 : 0xffffff800dcdab52 0xffffff811858bfb0 : 0xffffff800ddecd86
Kernel Extensions in backtrace:
com.apple.driver.AppleMuxControl(3.12.8) [3186B630-FFF4-32C9-BAB9-DCD0C9DB6BA2]@0 xffffff7f90e80000->0xffffff7f90e93fff
dependency: com.apple.driver.AppleGraphicsControl(3.1 2.8)[C57F5F56-2229-365F-9765-F24AA468758 4]@0xffffff7f90e78000
dependency: com.apple.iokit.IOACPIFamily(1.4)[5D7574 C3-8E90-3873-BAEB-D979FC215A7D]@0xffffff 7f8e7b3000
dependency: com.apple.iokit.IOPCIFamily(2.9)[5447B94 3-A94D-3BD4-A60F-98B24D19CE93]@0xffffff7 f8e52c000
dependency: com.apple.iokit.IOGraphicsFamily(2.4.1)[A 360453D-2050-3C49-A549-AC0DD5E87917]@0xf fffff7f8e941000
dependency: com.apple.driver.AppleBacklightExpert(1.1.0) [C49819CE-729A-36B2-9AC1-744A43DC236F]@0 xffffff7f90e7b000
com.apple.nvidia.classic.NVDAResmanTesla(1 0.0)[05FC5D7E-BB0B-3232-BBBD-8A49B6870D8 B]@0xffffff7f8e998000->0xffffff7f8ec0dff f
dependency: com.apple.iokit.IOPCIFamily(2.9)[5447B94 3-A94D-3BD4-A60F-98B24D19CE93]@0xffffff7 f8e52c000
dependency: com.apple.iokit.IONDRVSupport(2.4.1)[4EB 2843C-C821-3AD0-B333-575FD6ED6FB1]@0xfff fff7f8e988000
dependency: com.apple.iokit.IOGraphicsFamily(2.4.1)[A 360453D-2050-3C49-A549-AC0DD5E87917]@0xf fffff7f8e941000
com.apple.nvidia.classic.NVDANV50HalTesl a(10.0)[56199CA6-3C8D-3EBB-B5EF-7B1B4678 ACF9]@0xffffff7f8ec18000->0xffffff7f8eec 5fff
dependency: com.apple.nvidia.classic.NVDAResmanTesla(1 0.0.0)[05FC5D7E-BB0B-3232-BBBD-8A49B6870 D8B]@0xffffff7f8e998000
dependency: com.apple.iokit.IOPCIFamily(2.9)[5447B94 3-A94D-3BD4-A60F-98B24D19CE93]@0xffffff7 f8e52c000
com.apple.GeForceTesla(10.0)[07CD2F70-A8 DD-32EA-85C0-90433204BDAC]@0xffffff7f903 38000->0xffffff7f90403fff
dependency: com.apple.iokit.IOPCIFamily(2.9)[5447B94 3-A94D-3BD4-A60F-98B24D19CE93]@0xffffff7 f8e52c000
dependency: com.apple.iokit.IONDRVSupport(2.4.1)[4EB 2843C-C821-3AD0-B333-575FD6ED6FB1]@0xfff fff7f8e988000
dependency: com.apple.iokit.IOGraphicsFamily(2.4.1)[A 360453D-2050-3C49-A549-AC0DD5E87917]@0xf fffff7f8e941000
dependency: com.apple.nvidia.classic.NVDAResmanTesla(1 0.0.0)[05FC5D7E-BB0B-3232-BBBD-8A49B6870 D8B]@0xffffff7f8e998000 BSD process name corresponding to current thread: WindowServer

Mac OS version:
15G1004 Kernel version:
Darwin Kernel Version 15.6.0: Mon Aug 29 20:21:34 PDT 2016; root:xnu-3248.60.11 1/RELEASE_X86_64
Kernel UUID:
Kernel slide: 0x000000000da00000
Kernel text base: 0xffffff800dc00000
__HIB text base: 0xffffff800db00000
System model name: MacBookPro6,2 (Mac-F22586C8) kernel panic Macbook Pro mid 2010 с ошибкой по графике nVidea
Report Panic у MacBook Pro: дискретная видеокарта
Спонтанная перезагрузка MacBook Pro Mid 2010 Источник

MacBook Pro 6.2 (mid-2010) и чудесное исцеление GPU Panic

Моя винтажная «пятнашка» последние 3-4 месяца развлекала меня регулярными приступами паники особенно задорно. Прежде это тоже случалось, но не каждый месяц даже, а тут по 3-4 раза за день, иногда в крайне неподходящие моменты. Проблема известная, виновата дискретная графика (NVIDIA GeForce GT 330M в моем случае), программу бесплатного сервиса от Apple я проспал, платить $300+ за починку старинной железяки желания нет. Отсюда и идея с хакинтошем произошла.

Но вчера я вспомнил, что были и получше времена. Что изменилось? Sierra случилась, но это позже началось, вроде бы. Короче, вот магия, благодаря которой я уже почти сутки не видел серого экрана смерти. Нужно перейти в папку /Library/Preferences/ByHost/ (cmd-shift-g в Файндере) и удалить все файлы со словом windowserver в названии. В Терминале это будет rm Это все. Проблеме седьмой год, это решение я нашел в статье 2011 года. Жаль, что не нашел раньше. У меня в указанной папке было 2 файла на тему windowserver — один июльский, второй октябрьский. Есть подозрение, что где-то в октябре самый ад и начался. Я осознаю, что это не вполне решение проблемы — глюк хардверный, исцелить компьютер чисто программными средствами нельзя, но продлить агонию облегчить существование можно. Как это всё теоретически обосновать — загадка, а на практике я просто радуюсь. Файлы эти наверняка вернутся после очередного обновления macOS, но теперь я знаю где их искать и что с ними делать.

Диагностика и «лечение» критических ошибок системы (kernel panic)

Многие читатели встречались или хотя бы слышали о таком явлении, как «синий экран смерти» (BSOD), который появляется в операционных системах семейства Windows при возникновении критических ошибок системы, с которыми она не может справиться без полной перезагрузки. В OS X есть нечто похожее. Критические ошибки на уровне ядра Mac OS X называются «kernel panic». Ядро — сердце системы, отвечающее за взаимодействие как комплектующих и периферии, так и программного обеспечения вашего компьютера. Поэтому, если в работе ядра возникает критическая ошибка, часто для восстановления после неё требуется перезапуск ядра, а следовательно и системы. Чаще всего такие критические ошибки проявляются в виде серого экрана, на фоне которого на разных языках вас просят принудительно завершить работу компьютера в связи с возникновением ошибки. Однако так происходит не всегда. Иногда ошибки ядра приводят к полному зависанию системы или спонтанным перезагрузкам и выключениям компьютера. В этом случае основным признаком «kernel panic» будет появление соответствующей записи в логах системы с названием вида «Kernel_YYYY-MM-DD-HHMMSS_ComputerName.panic», где YYYY-MM-DD-HHMMSS — это последовательно указанные год, месяц, дата и время возникновения ошибки с точностью до секунд, а ComputerName — имя компьютера. К подобного рода ошибкам могут привести многие неисправности оборудования, как внутреннего (например, оперативной памяти), так и периферии (такой, как внешние накопители), а также сбои в работе ПО. К сожалению, при диагностике критических ошибок системы «круг подозреваемых» очень велик, так как ядро взаимодействует с каждым процессов и сервисом в системе, не говоря уже о каждом внешнем и внутреннем устройстве. Как и в многих других случаях с Mac OS X, при возникновении критических ошибок, намного проще опробовать несколько общих подходов для решения проблемы, чем при помощи отчетов и логов пытаться вычислить виноватого.

Возможные причины и решения.

Неисправность или сбои оперативной памяти (RAM)

Проблемы с оперативной памятью являются одной из самых распространенных причин возникновения критических сбоев. Если вам не удается проследить зависимость появления «kernel panic» от подключения каких-либо конкретных устройств или запуска определенных процессов, стоит проверить именно оперативную память. Для этого вы можете воспользоваться Функциональным тестом оборудования Apple (AHT) или, если ваш Mac выпущен после 2013 года, Apple Diagnostics. Если к компьютеру прилагался диск с программным обеспечением системы, вставьте его в оптический привод, выключите компьютер и нажмите клавишу D при следующем включении.

Устройства, поставлявшиеся с OS X 10.7 и выше также поддерживают запуск интернет-версии тестов. Для этого убедитесь, что ваш Mac подключён к сети Интернет и при запуске зажмите сочетание клавиш ⌥Alt + D. Для теста оперативной памяти также можно воспользоваться и сторонними утилитами, например, Rember или Memtest. Стоит также заметить, что некоторые версии системы или прошивок могут быть более (или менее) совместимы с тем или иным видом оборудования, в связи с чем их обновления могут привести к возникновению конфликтов с оборудованием и критических сбоев. Такое бывает редко и чаще случается наоборот, но все же вероятность есть.

Сбои NVRAM и SMC

В небольшом секторе памяти вашего компьютера под названием «энергонезависимое ОЗУ», или NVRAM, сохраняются определенные настройки, к которым OS X может быстро получить доступ. В настройки, сохраняемые в NVRAM, могут закрасться ошибки, которые в определенных случаях могут привести к появлению kernel panic. Для того чтобы устранить возможные ошибки памяти NVRAM стоит произвести её сброс. Для этого выключите компьютер и при следующем его включении зажмите клавиши ⌘Command + ⌥Alt/Option + P + R и удерживайте их до тех пор, пока компьютер не перезагрузится и вы не услышите сигнал загрузки во второй раз.

На более старых компьютерах Mac подобная информация сохранялась в параметрическом ОЗУ (PRAM). Сброс NVRAM на компьютерах Mac с процессорами Intel выполняется с помощью такой же комбинации клавиш и аналогичен сбросу PRAM.

Если вы пользуетесь беспроводной клавиатурой, есть небольшая вероятность, что компьютер не будет реагировать на нажатия клавиш на ней. В этом случае стоит подключить USB клавиатуру (не имеет значения, будь то клавиатура Apple или Windows) и повторить попытку с ней. Помимо этого на компьютерах Mac с процессором Intel установлен контроллер управления системой (SMC), который отвечает за многие низкоуровневые функции, такие как управление ресурсами аккумулятора, управление температурой, реакция на закрытие крышки портативных компьютеров и многие другие аспекты, связанные с питанием вашего Mac. В случае возникновения проблем с работой компьютера параметры SMC также стоит сбросить.

Выключите компьютер.
Подключите адаптер питания MagSafe или USB-C к источнику питания и к компьютеру.
Нажмите на встроенной клавиатуре одновременно клавиши ⇧Shift + Control + ⌥Alt/Option (слева) и кнопку питания.
Одновременно отпустите клавиши и кнопку питания.
Нажмите кнопку питания, чтобы включить компьютер.

На ноутбуках Mac со съемным аккумулятором:

Выключите компьютер.
Отключите адаптер питания MagSafe от компьютера, если он подключен.
Выньте аккумулятор.
Нажмите и удерживайте кнопку питания в течение пяти секунд.
Отпустите кнопку питания.
Снова подключите аккумулятор и адаптер питания MagSafe.
Нажмите кнопку питания, чтобы включить компьютер.

На Mac Pro, iMac, Mac mini и Xserve:

Выключите компьютер.
Отсоедините шнур питания компьютера.
Подождите 15 секунд.
Присоедините шнур питания.
Подождите 5 секунд, а затем нажмите кнопку питания, чтобы включить компьютер.

Сбои в работе внешних устройств (периферии)

Устройства Firewire, Tunderbolt и USB — также очень вероятные виновники возникновения критических сбоев. Причины могут самые разные, но основная заключается в том, что эти устройства очень часто обращаются к контроллеру вашего компьютера, обмениваясь с ним пакетами данных, и, если контроллер получит некорректный пакет, это может вызвать сбой.

В этом случае «kernel panic» могут возникать сразу при подключении устройства, при запуске системы, если устройство уже было подключено к Mac и в момент выхода компьютера из спящего режима.

В последнем случае одним из обходных вариантов может быть отключение перехода компьютера в спящий режим в меню Системные настройки → Экономия энергии.

Более же распространенный подход к данной проблеме обычно заключается в отключении всех внешних устройств и последовательном их подключении. Таким образом, методом перебора вариантов можно определить, какое устройство вызывает сбои, хотя это в некоторых случаях бывает довольно сложно, так как иногда проблема может проявляться не сразу, а через несколько минут, или даже часов.

Выяснив, какое устройство вызывает сбои, стоит проверить обновления прошивки этого устройства и драйверов для него, а также обновления самой системы. Есть вероятность, что проблема скорее программного характера и обновления её устранят.

Если вы пользуетесь концентраторами или разветвителями, позволяющими подключать одновременно несколько устройств к одному физическому порту на вашем компьютере, стоит хотя бы временно от них отказаться, так как они также могут вызывать критические ошибки.

Наконец, если ничего из описанного выше не помогло, стоит попробовать подключить аналогичное устройство другой модели или от другого производителя. К сожалению, так случается, что некоторые периферийные устройства могут быть несовместимы с вашим компьютером по той или иной причине.

Сбои в работе комплектующих

Регулярно повторяющиеся сбои могут быть вызваны неисправными, поврежденными или некорректно настроенными комплектующими, такими как встроенные Airport и Bluetooth контроллеры и прочие сетевые устройства, жесткие диски и твердотельные накопители, а иногда и неисправные или некорректно работающие процессоры.

Часто подобные проблемы могут решаться простым переподключением соответствующих комплектующих. Если вы недавно делали апгрейд своего Mac (особенно, если своими силами), стоит убедиться, что все PCI, PCI Express, AirPort и прочие платы расширения корректно подключены к соответствующим разъемам.

Ошибки кэша

Временные файлы, созданные системой и пользовательскими приложениями, играют важную роль в работе OS X, именно поэтому если в них появится какая-то ошибка, последующие обращения к ним могут привести к сбою. Перед тем, как приступить к подробной диагностике проблемы, стоит начать с очистки кэша, так как это может сэкономить ваше время и силы. Вы можете воспользоваться специализированными утилитами, вроде Onyx или Cocktail, или удалить временные файлы вручную. Какой бы вариант вы ни выбрали, настоятельно рекомендуем предварительно сделать полную резервную копию вашей системы!

Откройте Finder и нажмите сочетание клавиш ⌘Command + ⇧Shift + G
В открывшемся окне введите /System/Library
Нажмите кнопку «Перейти»
В открывшейся папке найдите файлы с названиями «Extensions.kextcache» и «Extensions.mkext» и удалите их.
В этой же директории найдите папку «Caches» выделите все её содержимое и удалите.
Снова нажмите сочетание ⌘Command + ⇧Shift + G и введите в открывшемся окне /Library/Caches/
Снова выделите и удалите все содержимое папки.
Наконец, ещё раз нажмите сочетание ⌘Command + ⇧Shift + G и введите в открывшемся окне

Некорректно работающее компоненты Mac OS X и расширения ядра

Компоненты Mac OS X и расширения ядра — это очень обширная тема, не только из-за того, что они уязвимы для огромного количества различных неисправностей, в числе которых повреждение данных, несовместимость оборудования, некорректная настройка прав доступа и многие другое, но и за счет своей многочисленности. Для примера можно заглянуть в папку /System/Library/Extensions, каждый файл в которой расширяет функционал ядра Mac OS X и может оказаться причиной причиной возникновения «kernel panic». В среднем система насчитывает около 250-300 расширений ядра (и это далеко не предел), что может превратить диагностику ошибки в поиск иголки в стоге сена.

В данном случае, если вы уверены, что проблема действительно кроется в системных файлах, может быть проще и эффективней провести повторную установку системы поверх существующей из раздела восстановления (попасть в который можно, зажав сочетание клавиш ⌘Command + R при включении компьютера), что оставит нетронутыми пользовательские данные, но заменит системные файлы на заведомо рабочие.

В некоторых случаях критические ошибки могут появиться после обновления или апгрейда системы, что также чаще всего относится к проблемам с системными файлами. Самым простым способом решения подобных проблем было бы восстановление из резервной копии на момент до обновления, однако есть у другие способы, которых мы писали в одной из наших предыдущих статей.

Некорректные настройки

Некорректные настройки вашей системы или повреждение самих файлов, в которых они хранятся также могут послужить причиной критических сбоев. Часто поведение системы может подсказать, какие параметры настроены неверно. Например, если проблема возникает при переходе компьютера или дисков (ввиду неактивности) в спящий режим или выходе из него, вероятно вам сможет помочь отключение функций в меню Системные настройки → Экономия энергии.

Если же определить источник проблемы не удается, можно использовать один из общих подходов и создать новую учётную запись. Таким образов вы сбросите для новой учётной записи все пользовательские настройки и сможете проверить, не решит ли это проблему. Если в новой учётной записи проблема устранилась, но её причину вам установить так и не удалось, возможно будет удобнее перенести все нужные вам данные в нового пользователя, а старого удалить.

Помимо этого может помочь запуск системы в безопасном режиме. Для этого выключите компьютер и при следующем включении зажмите клавишу ⇧Shift. Таким образом вы не только временно отключите все сторонние расширения ядра, дополнения системы и настройки, которые могут привести к сбоям, но и очистите некоторые временные файлы, которые также могут послужить причиной возникновения проблемы.

И, наконец, если у вас есть внешний носитель (флешка или внешний диск), вы можете провести чистую установку системы на него, затем перезагрузить компьютер и при включении зажать клавишу ⌥Alt/Option. В результате на экране отобразится список устройств, с которых можно осуществить загрузку системы. Выберите свой внешний диск и нажмите ⏎Enter. Таким образом вы сможете проверить работу компьютера с чистой системой без стороннего ПО и дополнительных пользовательских настроек.

Если описанные выше способы не дали положительного результата, можно почти с полной уверенностью сказать, что проблема имеет аппаратный характер. В этом случае попытки самостоятельного решения проблемы имеют мало шансов на успех. Стоит рассмотреть возможность обращения в сервисный центр для получения квалифицированной помощи при дальнейшей диагностике и устранения неисправности.