Cisco IOS 和 NX-OS 软件 : Cisco IOS 软件版本 12.1 主线

Cisco IOS 软件调度程序相关错误消息疑难解答

2015 年 8 月 28 日 - 机器翻译
其他版本: PDFpdf | 英语 (2015 年 4 月 22 日) | 反馈


目录


简介

本文解释一些思科IOS�软件调度程序相关的错误消息的原因,和如何排除故障他们。这些消息与一个特定平台没有涉及。他们能出现在每个平台该支持Cisco IOS软件。

这些是本文包括的消息:

如果遇到“SCHED…”在此页没有解释的错误消息,使用反馈表在此页顶部为了通知Cisco。

先决条件

要求

本文档没有任何特定的要求。

使用的组件

本文档不限于特定的软件和硬件版本。

规则

有关文档规则的详细信息,请参阅 Cisco 技术提示规则

背景信息

Cisco IOS软件调度器,是Cisco IOS软件内核的一部分,管理在系统的所有进程使用代表每个进程状态的一系列的进程队列。队列在该状态保持进程的上下文信息。当调度器移动他们的从一个进程队列的上下文到另一个,进程从一状态过渡到另一个。某些进程队列是:

  • 空闲队列—包含是活跃的在事件的进程,但是等待发生,在他们运行前。

  • 无效队列—包含终止的进程,但是需要有他们的回收的资源,在他们可以从系统前完全删除。

  • 就绪队列—包含合格运行的进程。有四个就绪队列,一个每流程优先级的。当运行进程挂起, CPU的调度器收复控制和使用一种算法选择从其四个就绪队列之一的下进程。

故障排除

SCHED-3-STUCKMTMR

当多种事件在路由器时,发生进程能注册通知。此特定留言看来,每当一个已注册计时器超时,并且计时器值在进程执行以后是不可更改两连续的倍。这总是一个装饰性的软件相关的问题。

在控制台的这些消息指示这样一问题:

%SCHED-3-STUCKMTMR: Sleep with expired managed timer 1C7410, 
time 0x1063F9C52 (00:00:00 ago).
-Process= "IP SNMP", ipl= 6, pid= 44
-Traceback= 31BC79A 31BC9C0 323E130

此错误消息出现的进程是缩小的这些traceback的原因一个好征兆。此列表显示这些消息的更多常见原因能发表:

  • IP简单网络管理协议(SNMP)进程—在SNMP WriteNet请求期间,此消息能出现:

    %SCHED-3-STUCKMTMR: Sleep w/expired mgd timer 13AF58, 
    time 0xBDBE878A (00:00:03 ago).
    -Process= "IP SNMP", ipl= 6, pid= 29
    -Traceback= 313B218 313B5D2 3192A76 319EFEC 319F234 30FF17E 319F446 319F88E 30FEA70 
    3304C1E 33045F0 32F78E4 32F82AE 32F383E 32F7ABA 30FF19A
    %SYS-4-SNMP_WRITENET: SNMP WriteNet request. Writing current configuration to 
    146.61.55.230.
    %SYS-4-SNMP_WRITENET: SNMP WriteNet request. Writing current configuration to 
    146.61.10.20.

    初期的Cisco IOS软件版本包含一些IP SNMP轮询相关的问题。对最新的Cisco IOS软件版本12.0或12.1主要版本的升级解决此问题。这是一个装饰性的消息,并且没有也许影响路由器的相反副作用(或IP SNMP进程的)操作。

  • 虚拟集成网络服务(VINES)协议进程—这些traceback在为VINES配置的路由器可以生成:

    %SCHED-3-STUCKMTMR: Sleep w/expired mgd timer 6100606C, time 0x222DF318 
    (00:00:00 ago).
    -Process= "VINES Protocols", ipl= 6, pid= 60

    消息他们发生,如果VINES未命中处理一个已到期计时的事件(当系统处理器大量地装载)时。没有,当首先超时时,事件最终得到处理,但是。

    VINES使用计时器处理和处理VINES地址解析服务(ARP)服务、处理器间通信(IPC)会话和重新传输、路由过期和一些服务器服务。

    这些消息在Cisco IOS软件版本12.0S和12.1主要版本修复。

  • 多协议标签交换(MPLS)有关的进程—这些traceback在为MPLS配置的路由器可以生成:

    %SCHED-3-STUCKMTMR: Sleep w/expired mgd timer 60C0E9B4, time 0x3952 
    (00:00:00 ago).
    -Process= "TDP Hello", ipl= 5, pid= 58
    -Traceback= 600867F0 60086BB8 604390D4 60077E88 60077E74
    
    %SCHED-3-STUCKMTMR: Sleep w/expired mgd timer 60CC2548, time 0x43006 
    (00:00:00 ago).
    -Process= "Tag Control", ipl= 5, pid= 56
    -Traceback= 600867F0 60086BB8 60448320 604484F0 60077E88 60077E74

    事件的分析为标签发行协议(TDP)循环, TDP Hello,并且标记控制进程显示环路可能呼叫一特定process_wait_for_event进程,无需处理所有超时的计时器。环路修复保证所有超时的计时器在暂停前处理。此问题在最新的Cisco IOS软件版本12.0S和12.1主要版本解决。

此消息能出现进程的此列表不详尽的。它总是一个装饰性的消息,并且,因此,不辩解Cisco IOS软件升级。请务必运行在您的系列的最新的Cisco IOS软件版本。如果消息在是可用的在Cisco.com为注册用户的最新的Cisco IOS软件版本仍然出现,请与思科技术支持联系开Case。此时,请提供完整show log错误消息和问题发生路由器或交换机的show tech

SCHED-3-THRASHING

此消息意味着指示的进程放弃了控制50连续的时间,并且有将处理的依然杰出的事件。

在控制台的这些消息指示这样一问题:

%SCHED-3-THRASHING: Process thrashing on watched queue 
'ARP queue' (count 54).
-Process= "ARP Input", ipl= 5, pid= 6
-Traceback= 6020589C 60205BC4 60236520 601F4FD8 601F4FC4

这些捶打的检查打算确定进程是否是,由于某种原因,不做其工作。在(的捶打的检查是麻烦消息发信号)的观看的队列检查元素数量在队列的。如果此编号为安排一定数量依然是同样,消息打印。

一些队列长度有限的。这意味着,如果路由器忙起来,队列总是坚持在最大数量。结果,在调度器的清理代码弄糊涂并且认为这些队列未被处理。清理代码确定应该处理队列的进程没有做其工作并且打印失效消息。

调度器更改用最新Cisco IOS软件编码。为了记录队列是否更改(因此它能改善确定进程是否捶打),当前调度器笔记,每当项目从队列删除,和只打印失效消息,如果什么都有一阵子不去除。

多数时间,队列失效消息是装饰性的。

这些消息总是由软件Bug没有导致的。他们可以发出以回应在路由器的瞬间或持续的需求。增加的或不变消息能表明数据流负载需要查看。

注意: 这些代码更改报告在Cisco Bug ID CSCdj68470 (仅限注册用户)下。

SCHED-3-UNEXPECTEDEVENT

此消息看来,每当进程接收不会处理的事件。例如:

%SCHED-3-UNEXPECTEDEVENT: Process received unknown event (maj 10, min 0).
-Process= "IP SNMP", ipl= 0, pid= 23
-Traceback= 602842B8 6017CFB8 6017CFA4

有此问题的几个可能的原因:

  • 最可能原因是一进程直接地叫醒另一进程,并且通过主要和次要的事件编号对进程。如果发送过程叫醒错误的进程,接收过程不会处理已接收主要和次要的事件编号。进程也许进行错误的操作,如果期待与匹配主要和次要的事件编号的一个事件,或者也许打印此消息。请使用输出show process命令帮助确定哪些进程也许已经发送直接唤醒到进程。

  • 此问题的另一个可能的原因是开发工程师添加代码登记事件,但是未添加代码处理事件。

  • 在退出前,进程呼叫的子例行程序可能为一个新的事件注册,但是未注销登记事件。

这些消息总是归结于软件Bug。基于不会处理事件的进程,您在Cisco IOS软件里能遇到不同的Bug。

如果进程与Exec或虚拟EXEC是相等的,您是很可能遇到这些问题:

%SCHED-3-UNEXPECTEDEVENT: Process received unknown event (maj 80, min 0).
-Process= "Exec", ipl= 0, pid= 20
-Traceback= 604A0D68 6049B400 6049C974 601B2F5C 601B338C 601CC384 601CC9E0 601F5628 
602383EC 602383D8

or

%SCHED-3-UNEXPECTEDEVENT: Process received unknown event (maj 80, min 0).
-Process= "Virtual Exec", ipl= 0, pid= 2
-Traceback= 60479FA0 60474638 60476474 601B0E20 601B0A38 601E5088 601E5B08 601F0A54 
60231324 60231310

此错误消息是由在一些旧版本编码偶然地被留下的调试代码造成的。它在Cisco IOS软件12.0主线版本再现了。错误消息可能出现,如果安排TACACS配置,并且执行show line命令在路由器的命令行界面(CLI)。错误消息没有在路由器的功能的影响,因此这可以考虑作为一装饰性的bug。摆脱此错误消息的唯一方法是升级Cisco IOS软件对一最新版本。

您必须根据您运行的系列运行至少Cisco IOS软件版本12.0(11), 12.0(11)S或者12.1(2)。然而,如果面对另一bug,请考虑到升级对对应的系列的最新的Cisco IOS软件联机。如果问题是存在最新的Cisco IOS软件版本,您能与思科技术支持联系打开一新的bug。此时,请有就绪完整输出show logging命令与错误消息和输出从show version为了解码traceback。

参考Cisco Bug ID CSCdp17107 (仅限注册用户)欲知关于此问题的详情。

SCHED-2-WATCH

此信息显示,每当尝试做出登记事件,无需首先创建该事件的数据结构。这是内部软件软件臭虫在Cisco IOS软件里。输出查找如此物:

%SCHED-2-WATCH: Attempt to enqueue uninitialized watched queue (address 0).
-Process= "Net Input", ipl= 0, pid= 29
-Traceback= 601B821C 60193428 604F59EC 604F6110 601C09F8 601934E0 6019304C 
  601A65E8 601A65D4

在线插拔任一种卡期间,您能遇到这一种错误消息。例如,在您替换在一个GSR12016系列路由器后的千兆路由处理器(GRP)卡在Cisco 12000SERIES互联网路由器,您能看到这些消息:

%SCHED-2-WATCH: Attempt to set uninitialized watched boolean (address 0).
-Process= "LC Crash Complete Process", ipl= 0, pid= 29
-Traceback= 60189CA8 60244E08 6017562C 60175618

代码更早版本包含一些冗余问题。大多这些问题在最新的Cisco IOS软件版本12.0S.修复请务必运行比或至少相等的与Cisco IOS软件版本12.0(18)S1和12.0(17)S2是以后的Cisco IOS软件版本。如果有故障的卡的重新安装不工作,路由器的冷重新加载应该很可能调整此问题。

消息类似于在7500系列路由器的此输出:

%OIR-6-REMCARD: Card removed from slot 3, interfaces disabled
%SCHED-2-WATCH: Attempt to set uninitialized watched Boolean (address 0).
-Process= "OIR Handler", ipl= 0, pid= 7
-Traceback= 60236120 60C64838 60280594 60280874 602211BC 602211A8

多数时间这些SCHED错误消息归结于内部软件软件臭虫在Cisco IOS软件里。所以,在排除故障这些错误消息的第一步将寻找已知bug。

对最新的Cisco IOS软件镜像的升级在您的版本系列摆脱所有已修复Cisco IOS软件调度程序相关的Bug。

如果问题仍然出现,与从show tech-supportshow log命令的输出一起请与您的与错误消息的确切的复制的Cisco支持人员联系。

建立 Cisco 技术支持案例时应收集的信息

如果还需要援助,在您遵从在本文后的故障排除步骤,您能开一个Case (仅限注册用户)有思科技术支持的。请务必包括列出的信息此处:
  • 显示错误消息的控制台获取。
  • 显示步骤您在每个步骤期间的控制台获取采取排除故障问题和启动顺序。
  • 出故障的硬件组件和机柜的序列号。
  • 故障排除日志。
  • show technical-support指令的输出。
请以非压缩的纯文本格式 (.txt) 将收集的数据附加到请求中。您能上传信息到您的情况用TAC Service Request Tool (仅限注册用户)。如果不能访问案例查询工具,您在一个电子邮件附件能发送信息对attach@cisco.com。包括您的案例编号在您的消息标题栏附上关于案例的相关信息。

注意: 请勿手工重新加载也请勿重新启动路由器,在您收集此信息前,除非要求。这能造成您丢失您需要为了确定问题的根本原因的重要信息。

相关的思科支持社区讨论

思科支持社区是您提问、解答问题、分享建议以及与工作伙伴协作的论坛。


相关信息


Document ID: 12422