获取控制台消息:ipc_kmsg_copyout_header:无法增加用户 ipc 空间。这里有 Mac OS X 内核专家吗?

获取控制台消息:ipc_kmsg_copyout_header:无法增加用户 ipc 空间。这里有 Mac OS X 内核专家吗?

自从从 Mac OS X 10.6.5 升级到 10.6.7 以来,我的电脑开始频繁锁定(通常至少每隔几天一次)。我会看到旋转的风车,系统将变得无响应(GUI 和 SSH 等)。这种状态将无限期持续,需要强制重启。当我积极使用计算机时,甚至在我不在的情况下,“闲置”数小时或数天,它都会进入这种不可恢复的旋转状态。这是不是内核崩溃。

重新启动后,我检查控制台日志以查看可能出现的问题。在每种情况下,系统启动消息开始之前总会显示相同的消息。它的内容如下:

2011/6/06 9:41:51 AM 内核 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

这是瞎猜,但你使用 Mozy 进行备份吗?我帮助另一个用户解决了一个问题,他的内核耗尽了与 IPC 相关的资源(在他的情况下具体是 Mach 端口),他最终将问题归咎于 Mozy。

某些 Mac 应用程序频繁崩溃,回溯中出现“__THE_SYSTEM_HAS_NO_PORT_SETS_AVAILABLE__”

即使您不使用 Mozy,您也可以尝试他所做的,打开活动监视器中的“端口”列,查看谁在使用 Mach 端口。显然,您必须在问题发生之前执行此操作,也许将其保持打开状态,以便您可以监控即将发生故障的早期迹象。您还可以打开“已发送的消息”和“已接收的消息”列,以查看哪个进程正在发送和接收最多的 IPC 消息。但在您对 kernel_task 发送/接收的所有消息感到惊讶之前,请务必与大约在同一时间重新启动的正常运行的机器进行比较,以获得基线。您还可以查看活动监视器中的进程列表,看看是否有过多的给定二进制文件副本在运行。

既然您似乎愿意深入研究内核源代码,那么您可能还想阅读如何调试内核问题:

在阅读了有关内核调试的介绍后,您可以尝试设置sudo nvram boot-args="debug=0x144"以启用几个常用的内核调试选项,然后,下次出现问题时,您可以按下电源键强制内核崩溃,以便您可以从另一台机器连接 GDB 并进行探索。如果您希望电源键恢复正常运行,请使用sudo nvram boot-args="debug=0x140"(保留其他很酷的选项,但禁用电源键 hack)或sudo nvram -d boot-args(删除整个“boot-args”NVRAM 变量)。

相关内容