Obtendo a mensagem do console: ipc_kmsg_copyout_header: não pode aumentar o espaço do ipc do usuário. Algum guru do kernel do Mac OS X aqui?

Question

Desde a atualização do Mac OS X 10.6.5 para o 10.6.7, meu computador começou a travar com frequência (geralmente pelo menos uma vez a cada dois dias). Eu vou pegar o cata-vento girando e o sistema ficará sem resposta (gui e ssh, etc). Esse estado durará indefinidamente, exigindo um reinício forçado. Ele entrará nesse giro irrecuperável quando eu estiver usando ativamente o computador ou, mesmo na minha ausência, "ocioso" por horas ou dias. Isso não é um kernel panic.

Ao reiniciar, verifico os logs do console para ver o que pode estar errado. Em todos os casos, há sempre a mesma mensagem que aparece logo antes do início das mensagens de inicialização do sistema. Ele lê algo como:

2011/6/06 9:41:51 AM kernel ipc_kmsg_copyout_header: can't grow user ipc space

com, claro, a data e a hora da última instância em que o computador estava respondendo. Nada mais incomum aparece antes desta mensagem. Apenas coisas de console padrão.

Pesquisando esta mensagem, eu só encontrei onde esta mensagem aparece no código-fonte ipc_kmsg.c, que parecem ser componentes dos kernels freebsd e mach

Aqui estão os links para a fonte relevante:

1) link

    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) link

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

3) (não é possível postar o terceiro link. novo usuário -_-)

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

Eu não quero fingir que sei exatamente o que está acontecendo aqui, mas parece que o kernel está ficando sem portas abertas para o ipc? Se este for o caso, o que poderia estar causando esse problema? O sistema não deve liberar as portas que não estão em uso? Não consigo pensar em nada que eu tenha instalado que possa usar todas as portas ipc.

Eu não vi nenhum outro post em nenhuma parte da internet sobre outras pessoas tendo esse problema, mas não consigo imaginar que sou a única pessoa a ter isso.

Obrigado, qualquer ajuda seria apreciada.

    

Answer 1

Este é um tiro no escuro, mas você está usando o Mozy para backup? Eu ajudei outro usuário com um problema em que seu kernel estava ficando sem recursos relacionados ao IPC (especificamente portas Mach no caso dele), e ele acabou rastreando até o Mozy.

Veja Alguns aplicativos do Mac travam com frequência, com" __THE_SYSTEM_HAS_NO_PORT_SETS_AVAILABLE__ "no backtrace

Mesmo que você não esteja usando o Mozy, tente o que ele fez e ative a coluna "Portas" no Monitor de atividades e veja quem está usando as portas Mach. Obviamente, você terá que fazer isso antes que o problema aconteça, talvez deixá-lo aberto para que você possa monitorar as coisas em busca de sinais precoces de que as coisas estão prestes a falhar. Você também pode ativar as colunas "Mensagens Enviadas" e "Mensagens Recebidas" para ver qual processo está enviando e recebendo a maioria das mensagens IPC. Mas antes que você fique surpreso com todas as mensagens de / para o kernel_task, certifique-se de comparar com uma máquina que está funcionando normalmente, que foi reinicializada quase ao mesmo tempo, para obter uma linha de base. Você também pode ver a lista de processos no Activity Monitor para ver se há cópias excessivas de um dado binário em execução.

Já que você parece querer explorar fontes do kernel, você também pode querer ler sobre como depurar problemas no kernel:

• Guia de programação do kernel
do Mac OS X da Apple
• Nota técnica TN2063: Entendendo e depurando pânicos de kernel
• Nota técnica TN2118: Core Dumps

Depois de ler a depuração do kernel, você pode tentar configurar sudo nvram boot-args="debug=0x144" para habilitar várias opções populares de depuração do kernel, e então, na próxima vez que o problema ocorrer, você pode pressionar sua tecla para forçar um kernel panic com GDB de outra máquina e bisbilhotar. Se você quiser que a chave de energia retorne à operação normal, use sudo nvram boot-args="debug=0x140" (deixe as outras opções legais ativadas, mas desative o hack de chave de energia) ou sudo nvram -d boot-args (remova toda a variável NVRAM "boot-args").