2

После обновления с Mac OS X 10.6.5 до 10.6.7 мой компьютер начал часто блокироваться (обычно не реже одного раза в пару дней). Я получу вращающуюся вертушку, и система перестает отвечать на запросы (как gui, так и ssh и т.д.). Это состояние будет длиться бесконечно, требуя принудительного перезапуска. Это войдет в необратимое вращение, когда я активно использую компьютер или даже в мое отсутствие, "простаиваю" несколько часов или дней. Это не ядро паники.

После перезапуска я проверяю журналы консоли, чтобы увидеть, что может быть не так. В каждом отдельном случае всегда есть одно и то же сообщение, которое появляется прямо перед началом сообщений о запуске системы. Это читает что-то вроде:

2011/6/06 9:41:51 AM kernel ipc_kmsg_copyout_header: невозможно увеличить пространство ipc пользователя

с, конечно же, датой и временем последнего экземпляра, на котором компьютер реагировал. Ничего необычного не появляется перед этим сообщением. Просто стандартный консольный материал.

Погуглив это сообщение, я наткнулся только на то, где это сообщение появляется в исходном коде ipc_kmsg.c, который является компонентами ядер freebsd и mach.

Вот ссылки на соответствующий источник:

1) http://fxr.watson.org/fxr/source/osfmk/ipc/ipc_kmsg.c?v=xnu-1456.1.26

    2963                 if (kr != KERN_SUCCESS) {
    2964                     /* space is unlocked */
    2965 
    2966                     if (kr == KERN_RESOURCE_SHORTAGE) {
    2967                         printf("ipc_kmsg_copyout_header: can't grow kernel ipc space\n");
    2968                         return (MACH_RCV_HEADER_ERROR|
    2969                             MACH_MSG_IPC_KERNEL);
    2970                     } else {
    2971                         printf("ipc_kmsg_copyout_header: can't grow user ipc space\n");
    2972                         return (MACH_RCV_HEADER_ERROR|
    2973                             MACH_MSG_IPC_SPACE);
    2974                     }
    2975                 }

2) http://fxr.watson.org/fxr/ident?v=xnu-1456.1.26;im=excerpts;i=MACH_MSG_IPC_SPACE

    658 #define MACH_MSG_IPC_SPACE              0x00002000
    659                 /* No room in IPC name space for another capability name. */

3) (не может опубликовать третью ссылку. Новый пользователь -_-)

    720 #define MACH_RCV_HEADER_ERROR           0x1000400b
    721                 /* Error receiving message header.  See special bits. */

Я не хочу притворяться, что точно знаю, что здесь происходит, но похоже, что в ядре заканчиваются открытые порты для ipc? Если это так, что может быть причиной этой проблемы? Разве система не должна освобождать порты, которые не используются? Я не могу думать ни о чем, что я установил, который мог бы использовать все порты ipc.

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

Спасибо, любая помощь будет оценена.

|источник

1 ответ1

1

Это выстрел в темноте, но вы используете Mozy для резервного копирования? Я помог другому пользователю с проблемой, когда в его ядре не хватало ресурсов, связанных с IPC (в частности, портов Маха в его случае), и он в итоге отследил его до Мозы.

См. Некоторые приложения Mac часто аварийно завершают работу с "__THE_SYSTEM_HAS_NO_PORT_SETS_AVAILABLE__" в обратном следе

Даже если вы не используете Mozy, вы можете попробовать то, что он сделал, и включить столбец "Порты" в Activity Monitor и посмотреть, кто использует порты Маха. Очевидно, вам придется сделать это до того, как возникнет проблема, возможно, оставив ее открытой, чтобы вы могли отслеживать вещи на предмет ранних признаков того, что они вот-вот потерпят неудачу. Вы также можете включить столбцы "Отправленные сообщения" и "Полученные сообщения", чтобы увидеть, какой процесс отправляет и получает наибольшее количество сообщений IPC. Но прежде чем вы будете удивлены всеми сообщениями в / из kernel_task, не забудьте сравнить с машиной, которая работает нормально, которая была перезагружена примерно в то же время, чтобы получить базовый уровень. Вы также можете посмотреть список процессов в Activity Monitor, чтобы увидеть, есть ли избыточные копии данного исполняемого двоичного файла.

Так как вы, похоже, готовы копаться в исходных кодах ядра, вы также можете прочитать о том, как отлаживать проблемы с ядром:

После прочтения об отладке ядра вы можете попробовать установить sudo nvram boot-args="debug=0x144" чтобы включить несколько популярных опций отладки ядра, а затем, когда в следующий раз возникнет проблема, вы можете нажать клавишу питания, чтобы вызвать ядро панику, чтобы вы могли присоединиться с GDB с другой машины и ковыряться. Если вы хотите, чтобы ваш ключ питания вернулся к нормальной работе, используйте sudo nvram boot-args="debug=0x140" (оставьте другие интересные опции включенными , но отключите взлом ключа питания) или sudo nvram -d boot-args ( затем удалите всю переменную NVRAM "boot-args").

|источник

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .