服务器 Gind.cn
  1. 服务器 Gind.cn
  3. 准确地说，每5分钟发生一次ECC CE（可纠正错误）
Intereting Posts
ASA访问列表和出口过滤 HP代码341“物理驱动器状态：预测失败。 预计这个物理驱动很快就会失败。“ SSH服务器，推送到客户端 Subversion隐藏存储库path 在Linode.com上设置nodebalancer后，IP欺骗攻击错误 克伦每15分钟就要重试一次工作 在CentOS 5.5上安装php-xml时出现错误 Ubuntu服务器崩溃的文件传输 SVNinput/输出错误 用于10 Gb连接的SFP电缆出现故障 我怎样才能自动删除旧的Apache的错误日志文件？ Windows 2008 R2 Hyper V性能 厨师节点和angular色的版本控制 MySQL的隐藏function 使用GIT设置Trac接收：“GIT后端不可用”

准确地说，每5分钟发生一次ECC CE（可纠正错误）

在我们的一个计算节点上，我得到了ECC CE（可纠正的错误）。 有一点奇怪的是，错误不是很大，只是每5分钟就发生一次。

messages.log： 

May 7 11:43:37 armada9 kernel: [22220081.676263] EDAC MC1: 1 CE on unknown memory (csrow:4 channel:1 page:0x41daad offset:0xc30 grain:0 syndrome:0x2254) May 7 11:48:37 armada9 kernel: [22220381.919057] EDAC MC1: 1 CE on unknown memory (csrow:4 channel:1 page:0x407bb8 offset:0x150 grain:0 syndrome:0x33a8) May 7 11:53:37 armada9 kernel: [22220682.161798] EDAC MC1: 1 CE on unknown memory (csrow:4 channel:1 page:0x41e6bd offset:0x6a0 grain:0 syndrome:0x33a8) May 7 11:58:37 armada9 kernel: [22220982.404501] EDAC MC1: 1 CE on unknown memory (csrow:4 channel:1 page:0x427c14 offset:0x880 grain:0 syndrome:0x33a8) May 7 12:03:37 armada9 kernel: [22221282.647210] EDAC MC1: 1 CE on unknown memory (csrow:4 channel:1 page:0x426e88 offset:0x830 grain:0 syndrome:0x33a8)

syslog示例条目： 

 May 7 12:03:37 armada9 kernel: [22221282.647114] [Hardware Error]: MC4 Error (node 1): DRAM ECC error detected on the NB. May 7 12:03:37 armada9 kernel: [22221282.647210] EDAC MC1: 1 CE on unknown memory (csrow:4 channel:1 page:0x426e88 offset:0x830 grain:0 syndrome:0x33a8) May 7 12:03:37 armada9 kernel: [22221282.647215] [Hardware Error]: Error Status: Corrected error, no action required. May 7 12:03:37 armada9 kernel: [22221282.647299] [Hardware Error]: CPU:6 (10:8:0) MC4_STATUS[Over|CE|MiscV|-|AddrV|CECC]: 0xdc54400033080813 May 7 12:03:37 armada9 kernel: [22221282.647393] [Hardware Error]: MC4_ADDR: 0x0000000426e88830 May 7 12:03:37 armada9 kernel: [22221282.647443] [Hardware Error]: cache level: L3/GEN, mem/io: MEM, mem-tx: RD, part-proc: SRC (no timeout)

另一件事比cat /sys/devices/system/edac/mc/mc*/csrow*/ce_count我的是cat /sys/devices/system/edac/mc/mc*/csrow*/ce_count显示4倍0 。 dmidecode -t memory | grep Size dmidecode -t memory | grep Size报告有8x 2GB骰子安装。 但是， cat /sys/devices/system/edac/mc/mc*/csrow*/size_mb显示了4x 4096 。 我猜测，内存芯片是单一的排名，而骰子加起来。 这个想法是对的吗？ 仍然不能解释为什么错误计数是0 。

这已经持续了大约2-3天。 到目前为止，每个错误都被报告为已更正，但这非常烦人，可能并不安全。

内存死亡，我很幸运，这只是一些系统进程发生在那里（而不是计算）？ 我不认为我每5分钟就有一次运行，但也许有一些日志工具。

或者原因可以是别的？

在我的PowerEdge R815中安装了新的DIMM时，也出现了类似的问题。 我认为其中一个DIMM是坏的，但不知道它可能是32个DIMM中的哪一个。 原来，硬件的LCD面板（和硬件日志）报告了故障，并提供了DIMM插槽ID。 当我重新安装DIMM时，错误消失了，所以这不是错误，毕竟可以通过ECC纠正。

将csrow和通道映射到物理插槽/ DIMM并尽快replace是非常重要的。 根据我的经验，你将会得到越来越多的错误，但这一切都取决于芯片完全坏的速度，我已经看到它从一天的一些错误进展到第二天的死亡，或者它可以使它几个月，或者更多（全部取决于你的工作量）。 最终，您的控制台将被充满，最终导致UE（无法纠正的错误），您的服务器将崩溃，并且DIMM将无法使用。

另一个重要的事情是，如果你的BIOS（和大多数服务器BIOS将这样做）检测到多个位故障，它可能会禁用该DIMM插槽。 不要在BIOS中擦除/清除或重置启用的DIMM，否则服务器可能根本无法启动（如在没有POST的情况下），除非您记得哪个DIMM被标记为坏，否则必须在芯片上移除芯片，直到启动哪一个是糟糕的（企业或数据中心环境下的巨大痛苦）。 另外，如果更换被标记为不良的DIMM，则可能必须重新启用该DIMM，或者擦除BIOS中的错误DIMMlogging以使其被识别。