标签: kernel-panic

我有持续的 oom&panic 情况未解决。我不确定系统是否填满了所有内存（36GB）。为什么这个系统会触发这种oom情况？我怀疑它与 32 位 linux 系统中的 lowmem 区域有关。如何分析内核恐慌和 oom-killer 的日志？

此致，

内核 3.10.24

Dec 27 09:19:05 2013 kernel: : [277622.359064] squid invoked oom-killer: gfp_mask=0x42d0, order=3, oom_score_adj=0
Dec 27 09:19:05 2013 kernel: : [277622.359069] squid cpuset=/ mems_allowed=0
Dec 27 09:19:05 2013 kernel: : [277622.359074] CPU: 9 PID: 15533 Comm: squid Not tainted 3.10.24-1.lsg #1
Dec 27 09:19:05 2013 kernel: : [277622.359076] Hardware name: Intel Thurley/Greencity, BIOS 080016  10/05/2011
Dec 27 09:19:05 2013 kernel: : [277622.359078]  00000003 e377b280 e03c3c38 c06472d6 e03c3c98 …

我正在运行一台生产 gentoo Linux 机器，最近有一种情况，服务器挂在我共同定位的地方，当我到达那里时，我注意到服务器挂在了似乎是内核崩溃挂起的地方。我通过硬重启重新启动了机器，但很失望地发现我无法在任何地方找到有关机器挂起原因的任何证据。

当我进行硬重启时，消息本身是否会丢失，或者是否有设置我可以在 syslog-ng 或 sysctl 中的某处进行设置以至少保留错误日志，以便我可以防止发生此类事故在将来 ？顺便说一下，我正在运行 2.6.x 内核。

提前致谢。

我们有几十台 Proxmox 服务器（Proxmox 在 Debian 上运行），大约每个月一次，其中一台服务器会出现内核崩溃并锁定。这些锁定最糟糕的部分是，当它的服务器位于与集群主服务器不同的交换机上时，该交换机上的所有其他 Proxmox 服务器将停止响应，直到我们找到实际崩溃的服务器并重新启动它。

当我们在 Proxmox 论坛上报告这个问题时，我们被建议升级到 Proxmox 3.1，过去几个月我们一直在这样做。不幸的是，我们迁移到 Proxmox 3.1 的其中一台服务器在周五因内核崩溃而锁定，并且同一交换机上的所有 Proxmox 服务器再次无法通过网络访问，直到我们能够找到崩溃的服务器并重新启动它。

嗯，几乎所有交换机上的 Proxmox 服务器......我发现有趣的是，同一交换机上的 Proxmox 服务器仍然在 Proxmox 1.9 版上不受影响。

这是崩溃服务器控制台的屏幕截图：

当服务器锁定时，同一台交换机上运行 Proxmox 3.1 的其余服务器变得无法访问，并发出以下信息：

e1000e 0000:00:19.0: eth0: Reset adapter unexpectedly
e1000e 0000:00:19.0: eth0: Reset adapter unexpectedly
e1000e 0000:00:19.0: eth0: Reset adapter unexpectedly
...etc...

uname -a 锁定服务器的输出：

Linux ------ 2.6.32-23-pve #1 SMP Tue Aug 6 07:04:06 CEST 2013 x86_64 GNU/Linux

pveversion -v 输出（缩写）：

proxmox-ve-2.6.32: 3.1-109 (running kernel: 2.6.32-23-pve)
pve-manager: 3.1-3 (running version: 3.1-3/dc0e9b0e)
pve-kernel-2.6.32-23-pve: …

我正在运行 FreeNAS 8 并且我的计算机因断电而硬重置，现在每次尝试启动时都会收到以下错误消息：

Error Message: panic: zfs_replay_acl_v0:898: unsupported condition

我正在使用 ZFS 文件系统版本 4、ZFS 存储池版本 15 运行 ZFS。有关如何解决此问题的任何想法？

我有一个可用的 TFTP/DHCP PXE 启动环境，我已经成功启动了一些映像。现在我构建了一个 CentOS 6.5 无盘映像，这个映像启动失败并出现以下错误：

No filesystem could mount root, tried:  iso9660
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0)

我按照以下方式构建了图像（遵循了这个优秀的教程）：

dd if=/dev/zero of=new-rootfs.img bs=1M count=512
mkfs.ext4 -F -j new-rootfs.img
<mounted and copied os from template host with rsync to /mnt>
gzip -c new-rootfs.img | dd of=new-rootfs.gz

我的 PXE 线如下：

    KERNEL vmlinuz0
    APPEND initrd=/images/centos-diskless/rootfs.gz root=/dev/ram0 init=/init noapic acpi=off devfs=nomount raid=noautodetect ramdisk_size=1048576 rw ip=dhcp

让我感到好奇的一件事是内核说仅尝试使用 iso9660 而不是 ext4（尝试使用 ext3 映像也不成功）。如何强制尝试使用 ext3/4？是不是图片有问题？

在这种情况下，我很乐意提供任何帮助！

我目前正在运行 Ubuntu 9.04、Jaunty，并且遇到了一些导致一些内核恐慌突然出现的问题。这些恐慌导致系统将一堆信息转储到终端并挂起。

通常，这些会在我离开系统时发生。这意味着系统一直处于空闲状态，直到我来到终端，看到它发生了内核恐慌，然后重新启动系统。

有没有办法用 Linux 自动重启？我知道对于 Windows BSOD，有一个选项可以在发生核心转储后自动重新启动。Linux 有类似的选项吗？

在半定期的基础上，我看到 GCE 实例冻结并显示以下错误消息（来自串行控制台）：

g[1375589.784755] BUG: unable to handle kernel NULL pointer dereference at 0000000000000078
g[1375589.786206] IP: [<ffffffff810a67d9>] check_preempt_wakeup+0xd9/0x1d0
g[1375589.787341] PGD 5da04067 PUD db83067 PMD 0 
g[1375589.788607] Oops: 0000 [#1] SMP 
g[1375589.788705] Modules linked in: veth xt_addrtype xt_conntrack iptable_filter ipt_MASQUERADE iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 ip_tables x_tables nf_nat nf_conntrack bridge stp llc aufs(C) softdog crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel aes_x86_64 processor psmouse parport_pc parport i2c_piix4 i2c_core thermal_sys lrw virtio_net evdev pcspkr serio_raw gf128mul glue_helper ablk_helper cryptd button ext4 crc16 mbcache jbd2 sd_mod …

我安装了全新的 CentOS 6.5，其中包含两个（安装到 /mnt/data）1tb Western Digital Black 驱动器，位于 raid 1 中，带有 mdadm，通过安装程序进行配置。不幸的是，整个系统内核时不时地出现恐慌，并出现类似于下面的跟踪：

有关诊断或修复此问题的任何提示吗？非常感激！

编辑：看来这发生在 raid 数据检查发生的大约同一时间： 编辑 2：最后两次崩溃发生在周日凌晨 1 点刚过，同时进行数据检查。

Mar 23 01:00:02 beta kernel: md: data-check of RAID array md0
Mar 23 01:00:02 beta kernel: md: minimum _guaranteed_  speed: 1000 KB/sec/disk.
Mar 23 01:00:02 beta kernel: md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for data-check.
Mar 23 01:00:02 beta kernel: md: using 128k window, over a total of 976629568k.

/proc/mdstat

    Personalities : [raid1] …

在尝试将一个相当大的文件夹 (450G) 备份到该服务器中的 2TB 驱动器时，该驱动器仅作为备份目标rdiff-backup（版本 1.2.8 - 最后标记为stable）导致内核崩溃。

系统：

Linux giorgio 3.2.0-4-amd64 #1 SMP Debian 3.2.51-1 x86_64 GNU/Linux

磁盘：软件镜像RAID模式下2块1TB磁盘，1块2TB磁盘专用于备份。

我有一个怀疑：服务器上的内存是2G RAM + 2G swap = 4G。文件大小最大为 16G。是否有可能rdiff-backup在某个时候将整个文件加载到内存中？

在任何情况下，都不应该发生内核恐慌（因为 rdiff 进程被杀死了？所以内存应该再次可用？），所以我想我的问题有两部分，一：关于我的怀疑，二：关于内核恐慌。

顺便说一下，恐慌是最近开始的，相当多的备份已经成功——完整的和增量的——并且那些大 GB 文件已经存在。所以我猜这是新的 Debian 内核的错而不是 rdiff-backup 的错？

发生恐慌时的日志文件部分http://pastebin.com/e9a5fQdh

屏幕上的最后一件事：

编辑/更新：我刚刚尝试创建一个 20GB 的交换文件（使用来自 /dev/zero 的 dd）并且服务器再次关闭，对ping.

从查看日志来看：似乎内核已经杀死了一些进程 - 包括我怀疑导致这一切的那个进程（rdiff-backup） -但说“耗尽了可杀死的进程”。似乎杀死进程并没有释放内存？

服务器在编译 PHP 5.4.9 时抛出“内核：哎呀：0000 [1] SMP”。

当我再次尝试以确保它是罪魁祸首时它崩溃了。

除此之外，服务器工作正常。

它有点旧并且在非常旧的操作系统上运行：2.6.23.17-88.fc7

在服务器停止响应之前，我检查了 dmesg 日志是否有错误，但没有。

我是否缺少任何日志？关于如何解决此内核恐慌的任何提示？

我想补充一点，我也编译了 Nginx，但一切顺利。