Obtenir un message de console: ipc_kmsg_copyout_header: ne peut pas augmenter l'espace ipc de l'utilisateur. Tous les gurus du noyau Mac OS X ici?

Depuis la mise à niveau de Mac OS X 10.6.5 vers 10.6.7, mon ordinateur a commencé à se verrouiller fréquemment (généralement au moins une fois tous les deux jours). Je recevrai la bobine tournante et le système deviendra non réactif (gui et ssh, etc.). Cet état durera indéfiniment, nécessitant un redémarrage forcé. Il entrera dans cette rotation irrécupérable lorsque j'utilise activement l'ordinateur ou même en mon absence, «inactif» pendant des heures ou des jours. Ce n'est pas une panique de kernel.

Au redémarrage, je vérifie les journaux de la console pour voir ce qui pourrait être incorrect. Dans chaque cas, il y a toujours le même message qui apparaît juste avant le début des messages de démarrage du système. Il lit comme suit:

06/06/06 9:41:51 AM kernel ipc_kmsg_copyout_header: ne peut pas augmenter l'espace ipc de l'utilisateur

Avec, bien sûr, la date et l'heure de la dernière instance que l'ordinateur répondait. Rien d'autre inhabituel apparaît avant ce message. Juste des éléments de console standard.

En recherchant ce message, je n'ai rencontré que ce message s'affiche dans le code source ipc_kmsg.c, qui semblent être des composants des noeuds freebsd et mach

Voici les liens vers la source pertinente:

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) (ne peut pas afficher le 3ème lien. Nouvel utilisateur -_-)

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

Je ne veux pas faire semblant de savoir exactement ce qui se passe ici, mais il semble que le noyau manque de ports ouverts pour ipc? Si tel est le cas, qu'est ce qui pourrait causer ce problème? Le système ne devrait-il pas libérer des ports qui ne sont pas utilisés? Je ne peux pas penser à tout ce que j'ai installé qui pourrait utiliser tous les ports ipc.

Je n'ai vu aucun autre message sur les internautes sur d'autres personnes ayant ce problème, mais je ne peux pas imaginer que je suis la seule personne à l'avoir.

Merci, toute aide serait appréciée.

C'est un coup dans l'obscurité, mais utilisez-vous Mozy pour la sauvegarde? J'ai aidé un autre utilisateur avec un problème où son noyau manquait de ressources liées à l'IPC (en particulier les ports Mach dans son cas), et il a fini par le suivre à Mozy.

Voir Certaines applications Mac échouent fréquemment, avec "__THE_SYSTEM_HAS_NO_PORT_SETS_AVAILABLE__" dans backtrace

Même si vous n'utilisez pas Mozy, vous pouvez essayer ce qu'il a fait et allumer la colonne "Ports" dans Activity Monitor et voir qui utilise les ports Mach. De toute évidence, vous devrez le faire avant le problème, peut-être le laisser ouvert afin que vous puissiez surveiller les choses pour les signes précurseurs que les choses sont sur le point d'échouer. Vous pouvez également activer les colonnes "Messages envoyés" et "Messages reçus" pour voir quel processus envoie et reçoit la plupart des messages IPC. Mais avant de vous surprendre de tous les messages à partir de la kernel_task, assurez-vous de comparer à une machine qui fonctionne normalement, qui a été redémarré à peu près au même moment, pour obtenir une ligne de base. Vous pouvez également consulter la liste des processus dans Activity Monitor pour voir s'il existe des copies excessives d'une exécution binaire donnée.

Puisque vous semblez disposé à creuser dans les sources du noyau, vous pouvez également lire comment réparer les problèmes du noyau:

  • Guide de programmation du kernel Mac OS X d'Apple
  • Note technique TN2063: Compréhension et débogage Kernel Panics
  • Note technique TN2118: Déchets de noyau de noyau

Après avoir lu le débogage du noyau, vous pouvez essayer de définir sudo nvram boot-args="debug=0x144" pour activer plusieurs options populaires de débogage du noyau, puis la prochaine fois que le problème frappe, vous pouvez appuyer sur votre touche d'alimentation pour forcer un noyau Panique afin que vous puissiez attacher avec GDB à partir d'une autre machine et poke autour. Si vous voulez que votre touche d'alimentation revienne au fonctionnement normal, utilisez sudo nvram boot-args="debug=0x140" (laissez les autres options intéressantes, sudo nvram boot-args="debug=0x140" , mais désactivez la clé de sudo nvram -d boot-args ) ou sudo nvram -d boot-args ( Supprime alors la variable NVRAM "boot-args" entière).