System Management Services (SMS) 1.5 发行说明

本章将介绍有关已知 SMS 1.5 错误的信息，还将对那些在 SMS 修补程序（支持 UltraSPARC IV+ 处理器）中修复的错误进行介绍。本章包括以下内容：

• 本次更新中修复的错误
• SMS 1.5 软件中的已知错误
• SMS 1.5 文档勘误

---

本次更新中修复的错误

本节介绍 SMS 1.5 软件中的错误，以及在支持 UltraSPARC IV+ 处理器的 SMS 修补程序中修复的相关错误。

增强了 UltraSPARC IV+ CPU 的错误处理能力 (CR ID 6257778)

修补程序 120843-01 增强了 OpenBoot PROM 的错误处理和恢复能力，使其可以包含 UltraSPARC IV+ 处理器。

prtdiag 显示的 C5 插槽的总线频率不正确 (CR ID 6286277)

以热插拔方式将一块卡插入插槽 1 (c5v0) 并重新启动系统之后，对于插有卡的插槽，prtdiag 显示了正确的总线频率，但对于其他空插槽，显示的总线频率却不正确。这一错误已在修补程序 120843-01 中得以修复。

在具有双核心 UltraSPARC IV+ 的 Starcat 上出现 "PCI IOC ECC Tests" 失败，诊断级别为 64 或更高 (CR ID 6255743)

在安装了双核心 UltraSPARC IV+ 板的 Sun Fire E25K/E20K 系统上，lpost 可能会在诊断级别 64、96 或 127 处失败。发生这种失败时，lpost 会返回以下错误消息：

{SB03/P0/C1} ERROR: TEST=PCI IOC Ecc Tests,SUBTEST=PCI IOC ECC 

修补程序 120648-02 解决了此问题。

修改了 hpost 以支持 1500 MHz 的 UltraSPARC IV+ GA (CR ID 6270911)

SMS 1.5 中的 hpost 需要进行修改，以支持 UltraSPARC IV+ 板。修补程序 120648-02 进行了这一修改。

从 Solaris 重新引导时，hpost -q 失败并显示 "Out Of Config on Timeout" (CR ID 6324035)

如果重新引导 UltraSPARC IV+ 板上的域,则正在运行 UltraSPARC IV+ 板上的 Solaris 9 4/04 OS 的 Sun Fire E25K/E20K 系统有时会超时。该系统会返回以下错误消息：

Proccore SB0/P0/C0 timed out on test Domain Advanced Tests id=0x6F. Test Failed.FAIL Proccore SB0/P0/C0: test_seq_cwd(): failed out of config on timeout

(Timeout Secs Given: 30)

修补程序 120648-02 解决了此问题。

UltraSPARC IV+ 2.1 以前的版本应仅为内部版本 (CR 6292571)

为客户系统发行的首批 UltraSPARC IV+ 处理器的版本是 2.1.1。修补程序 120648-02 修改了 POST 以检测版本早于 2.1 的处理器，这类处理器不符合交付客户使用的条件，因此不会对它们进行配置。

注意从 MaskID 上是无法区分版本 2.1 和 2.1.1 的，因为它们都被标记为 2.1。POST 是根据读取到的其他电子信息来区分它们的。

UltraSPARC IV+：PN 1500 MHz 上的 marginvoltage vcore 负值没有显示正确的边界电压 (CR 6288445)

此错误仅出现在 1500 MHz 的 UltraSPARC IV+ 板上。使用带有 -m-1 选项的 marginvoltage 命令偶尔会返回不正确的值。如果隔几秒钟之后重新执行该命令，便可以返回正确的值。这一错误已在修补程序 120789-01 中得以修复。

UltraSPARC IV+：UltraSPARC IV+ vcore 的 marginvoltage 输出格式不正确 (CR 6290143)

此错误仅出现在 1500 MHz 的 UltraSPARC IV+ 板上。使用带有 -m-1 或 -m+1 选项的 marginvoltage 命令时，系统会返回不正确的输出格式。例如，在 UltraSPARC IV+ 板上使用 -m+1 命令会返回更改后的值 Nom (电压)，而非 Nom+3% (电压)。而在 UltraSPARC IV 和 UltraSPARC III 板上执行同样的命令则可以返回正确的输出格式。修补程序 120789-01 解决了此问题。

RFE: AVL-FS2 (Starcat)：提供对于新 UltraSPARC IV+ CPU 错误的诊断 (CR ID 6277467)

与 UltraSPARC IV 和 III+ 处理器比较而言，UltraSPARC IV+ 处理器具有更强的错误检测和 RAS 能力。此 CR 介绍对“可用性”功能进行的增强，该增强功能可对 UltraSPARC IV+ 报告的新错误进行诊断。有了这项增强功能，“可用性”功能可以诊断所有处理器类型的所有致命错误，以及 Solaris 9 域中的非致命错误。修补程序 120827-01 提供了这项增强功能。

SC CPU 需要处理非 FMA 域中的 L3/L2 高速缓存错误，以避免导致处理器波动 (CR ID 6302265)

UltraSPARC IV+ 芯片具有三种级别的高速缓存。级别 2 和 3 是数据高速缓存；级别 2 供处理器在内部使用，级别 3 供处理器在外部使用。

有时一个错误会连带导致其他错误（即，产生副作用）。当这两个级别中任一级别的数据高速缓存中出现错误时，“可用性”软件会诊断导致该错误的根本原因，并忽略那些连带产生的错误。这样做不仅有利于诊断，还能避免相关组件因受连带错误牵连而被误认为出现了故障。修补程序 120827-01 解决了此问题。

hwad 连续发送 Dstop 事件导致延迟和错误的 dsmd ASR (CR ID 6302843)

在运行多个域的系统中，出现错误情况之后，hwad 必须首先向每个正在运行的域发出 dstop（域停止）事件，然后 dsmd 才能恢复这些域。由于这些 dstop 事件是一个接一个地发出的，因此从时间上来看，从发出第一个 dstop 事件到所有域均被恢复之间总会有些延迟。

修补程序 120789-01 解决了这一问题，它令所有 dstop 各自使用单独线程以并行方式向域发出，从而消除了延迟。

SERD 对于 CPU 事件的可调性在 S9U8、S10U1/FMA 和 SMS 1.5 之间不一致 (CR ID 6309365)

为描述 UltraSPARC IV+ 处理器中新增的高速缓存级别，SC 端的软性错误率鉴别器 (Soft Error Rate Discriminator, SERD) 需要使用不同的阈值与 Solaris 9 域中现有的阈值相匹配。如不进行该调整，则在执行 SC 端的诊断之前，域会使处理器脱机，从而导致处理器的运行状态无法正确更新。

修补程序 120827-01 解决了这一问题，使得这些诊断在这两种操作系统版本和 SMS 1.5 软件之间对于所有支持的处理器类型都是一致的。

---

SMS 1.5 软件中的已知错误

本节概述了对 SMS 1.5 有重要影响的错误。

发往 NetConnect 的 FMA 事件报告不显示修改过的底盘序列号 (CR ID 5052078)

如果运行 Sun Fire 高端服务器时，没有使用 setcsn 命令在 SC 上设置底盘序列号 (CSN)；则在发生域停止 (Dstop) 事件后，发往 NetConnect 的所有故障管理体系结构 (FMA) 报告会在其事件报告中将该序列号显示为空。

解决方法：使用 setcsn 命令设置底盘序列号，然后重新启动 SMS。您必须重新启动 SMS，CSN 才会显示在事件报告中。

有关如何在 SC 上设置底盘序列号的详细信息，请参阅《System Management Services (SMS) 1.5 安装指南》。

ndd/dev/scman man_pathgroups_report 输出内容需要辨别 (CR ID 6252771)

为了读取和写入特定设备驱动程序参数，可以用超级用户身份执行 ndd(1M) 命令。 scman(7D) (ndd/dev/scman) 命令可用来对管理 (MAN) 网络的 Sun Fire E25K/E20K SC 端进行管理，它支持使用 ndd(1M) 命令。

如果未正确解释 scman(7D) 的 man_pathgroups_report 参数，当实际发生了由软件引起的错误时，系统可能会报告发生了严重的硬件错误。并因此得出错误的结论：需要更换硬件以便从根本上解决问题。

当指定了 man_pathgroups_report 参数时，您可以得到类似如下的输出：

# ndd /dev/scman man_pathgroups_report

MAN Pathgroup report: (* == error)

Interface       Destination             Active Path     Alternate Paths

----------------------------------------------------------------

scman1          Other SSC               eri0 eri0 exp 0, hme1 exp 0 *

最后一行中的星号 (*) 表示“上一次使用 hme1 物理端口时，发生了错误”。从历史经验判断，此类错误多数是由软件而非硬件问题所致。

当 MAN 网络中的对等设备不再对“心跳”消息作出响应，或者存在错误的 dlpi(7P) 状态过渡时，会因软件问题而发生错误。以超级用户身份运行以下命令可再现前一种情形（假定确切的输出内容如上所示）：

# ndd -set /dev/scman man_set_active_path '1 0 1'

对于执行命令的 SC（如 SC0）来说，其活动路径已由 eri0 切换至 hme1。在一段时间内，SC1 会继续通过 eri0 物理接口发送数据包，SC0 则会继续通过 hme1 发送数据包。稍后，SC1 和 SC0 将使用同一个接口进行同步和通信。然而，每台 SC 上却会显示一个星号，以表示上一个端口发生了错误。这种情况下，该错误确实是由软件问题导致的（即错误的确是因未响应“心跳”消息序列而致）。该错误不是致命的硬件错误。

如果确实存在持久而致命的硬件错误，上面的输出中也会显示星号。但却不应假定硬件问题是导致显示星号的唯一原因。

---

SMS 1.5 文档勘误

本节概述了 SMS 1.5 手册页以及文档中的错误。

marginvoltage(1M)

marginvoltage 手册页中有以下陈述：

边界设置有可能在断电通电的过程中发生改变。

这种说法的正确性仅限于核心电压。所有其他设置在此过程中都会保持不变。

rcfgadm(1M)

CR ID 4945049

rcfgadm(1M) 手册页中的注释应为：

如果 rcfgadm 命令失败，板不会返回其最初的状态。dxs 或 dcs 错误消息将被记录到域中。如果错误可恢复，您可以重试该命令。

如果域中运行的是 Solaris 8 或 Solaris 9 OS，请执行以下检查：

1. 重试该命令之前，应确保域内的 /etc/inetd.conf 文件中包含以下 dcs 条目，且这些条目未被禁用。

sun-dr stream tcp wait root /usr/lib/dcs dcs

sun-dr stream tcp6 wait root /usr/lib/dcs dcs

2. 如果错误不可恢复，则必须重新引导域以便使用该板。

如果域中运行的是 Solaris 10 OS，则 dcs 是 SMF（Service Management Facility，服务管理工具）的一部分。执行以下步骤：

1. 确保以超级用户的身份登录。

2. 在域的系统提示符下键入以下命令：

# inetadm | grep dcs

disabled disabled svc: /platform/sun4u/dcs: default

3. 如果 dcs 已禁用（如上例所示），请键入以下命令将其启用：

# svcadm enable svc:/platform/sun4u/dcs:tcp 

testemail(1M)

CR ID 5047803

testemail(1M) 手册页中有关 -c 选项的描述应为：

testemail 用于生成事件的错误类或以逗号分隔的错误类列表。

-c 错误类， 错误类， 错误类

/etc/opt/SUNWSMS/config/SF15000.dict 文件中提供了有效的错误类实例。

CR ID 6221370

描述部分的注释应为：

使用 Ecache 资源调用 testemail 之前，应接通包含 Ecache 的系统板的电源。否则，对 testemail 的调用将失败，也不会生成电子邮件。

《System Management Services (SMS) 1.5 Administrator Guide》

第 1 章的第 5 页：

有关 VCMON 的描述应为：

SMS 软件中新增了一个电压核心监视参数 (Voltage Core Monitoring Parameter, VCMON)。启用 VCMON 后，它可以监视处理器电压的任何变化或浮动。如果 VCMON 检测到电压有上升趋势（一般表示插座连接存在问题），就会通过 FMA 事件通知用户，并将该处理器的组件运行状况 (CHS) 标记为故障。

第 10 章的第 190 页：

在有关 showboards 命令的描述中，-a 选项应为 -v。

在有关 showenvironment 命令的描述中，应删除类别 "Device"。

第 11 章的第 201 页：

第一个实例应为：

showlogs -d 域指示符 -p s

第二个实例应为：

showlogs -d 域指示符 -p c

附录 A 的第 247 页：

应添加以下命令：

smsinstall：安装 SMS 软件。

smsupgrade：升级安装在系统中的现有 SMS 软件。

附录 B（CR 6227544、4943474）：

应在错误代码 11300 与 50000 之间添加以下错误消息类别：

11500-11699：保留用于 EFHD 消息

11700-11899：保留用于 ELAD 消息

11900-12099：保留用于 ERD 消息

12100-12299：保留用于事件实用程序消息

12300-12499：保留用于 Wcapp 消息

12500-12699：保留用于与 FRUID 相关的消息

12700-12799：保留用于 EBD 消息

《System Management Services (SMS) 1.5 安装指南》

第 5 页：

硬件兼容性表（表 1-2）应将 Solaris 8 2/02 列为 Solaris 8 软件中第一个同时支持域和系统控制器 (SC) 的版本。

该表在印刷方面有一个错误，它出现在 1.65 MHz UltraSPARC 处理器处。正确的速度应为 1.5 MHz。

如安装指南所述，SMS 1.5 支持 2 GB 和 4 GB 的 /swap 分区大小。建议使用的 SMS 1.5 分区大小如下：

第 14 页：

在禁用故障转移之前必须启动并运行 SMS。

第 15 页：

要检验是否已安装了 Java 版本 1.2.2，在系统提示符下键入 java -version。

第 3 步应为：

运行 smsupgrade 命令以便重新安装 SMS。

第 26 页：

在记录底盘序列号 (Chassis Serial Number, CSN) 之前必须启动并运行 SMS。

第 37 页：

实例中应显示 sc0，而非 sc1。

第 38 页：

flashupdate 实例中缺少 -f 开关。该实例应为：

-f /opt/SUNWsms/hostobjs/sgcpu.flash

第 41 页：

在此过程的第 2 步之后应该有第 3 步。第 3 步应为：

升级 Solaris OS。请参见第 31 页的“安装或升级 SC 上的 Solaris OS”。

第 3 步之后应有第 4 步，第 4 步应为：

执行完主 OS 升级（请参见第 31 页）后，请运行 smsupgrade 以重新安装 SMS。否则，请继续执行下一步，以恢复 SMS 配置。

标题“重新安装 SMS 软件”应为“恢复 SMS 配置”。

System Management Services (SMS) 1.5 发行说明

819-3301-11

版权所有 © 2005, Sun Microsystems, Inc. 保留所有权利