|
|
This chapter explains how to diagnose and handle LIM controller module events generated by the Cisco 6100 Series system. The following information is presented for each of the events:
If none of the actions presented for the event are successful, contact the Cisco Technical Assistance Center (TAC) for additional support.
Table 14-1 lists LIM controller module events and their IDs, definition, severity, and description. A detailed explanation of these events and corrective actions required (if any) is located in subsections in this chapter.
| ID | Definition | Severity | Description |
|---|---|---|---|
2 | SCL_SOFTWARE_FAILED_CRC | Minor | Software failed CRC check during download |
3 | SCL_OUT_OF_MEMORY | Critical | Application was unable to allocate memory |
128 | LR_CREATE_OBJ | Info | Module was detected |
129 | LR_PING_FAIL | Critical | Module did not respond to system monitor |
| ID | Event Name | Severity |
|---|---|---|
2 | SCL_SOFTWARE_FAILED_CRC | Minor |
The following description appears in the ViewRunner for Windows Event History View dialog box or the ViewRunner for HP OpenView Error Events Browser:
Software failed CRC check during downloadEvents of this type are not run-time events. They occur only during module power up and self-test, and they do not affect service (because subscriber service is typically not active yet). The module fails self-test as a result of this event, and immediately retries the self-test, but no self-test will end in success. A failure message is generated with each failure. Without a successful self-test, the module cannot be put into service, so the node does not complete its installation cycle.
Software update events fall into this description, because it is assumed that the updates are always monitored by an operator. Consequently, the events need not be coded as critical. In any case, the goal is to monitor the node status until the node becomes fully operational.
Alarm events of this type are generated only during module initialization and automatically force a module reset.
Step 1 If the reset condition continues (the module does not exit self-test mode), reinsert the module.
Step 2 If a problem persists, replace the module.
| ID | Event Name | Severity |
|---|---|---|
3 | SCL_OUT_OF_MEMORY | Critical |
The following description appears in the ViewRunner for Windows Event History View dialog box or the ViewRunner for HP OpenView Error Events Browser:
Application was unable to allocate memoryAn event of this severity causes loss of service for more than four subscribers. Here are two examples of this type of event:
In some cases, a module forces itself into a self-test based on the alarm condition. In other cases, the system controller (SC) module forces the alarmed module to reset. A module reset forces the module to be power cycled, self-tested, and reconfigured into the slot by the SC module.
Several alarm event conditions are cleared by a module reset. Look for the alarm event to clear within 1 minute. An alarm event is cleared when the SC module faceplate alarm LED changes from red to off.
In the ViewRunner management software, two actions show that an alarm event is cleared:
If the alarm event does not clear:
Step 1 Remove and reinsert the module. This forces a module to reset if neither the module nor the SC module could force a reset. A module reset usually clears all alarm conditions.
Step 2 Observe the SC module alarm LED or the ViewRunner ejector tabs to see if the alarm condition returns. If the previous problem persists, the condition will probably reoccur within 1 minute.
Step 3 If the alarm condition persists, replace the module.
| ID | Event Name | Severity |
|---|---|---|
128 | LR_CREATE_OBJ | Info |
The following description appears in the ViewRunner for Windows Event History View dialog box or the ViewRunner for HP OpenView Error Events Browser:
Module was detectedEvents of this type do not indicate service impairment or loss.
This is an information event, not an alarm event. Information events do not represent a state change and therefore are not followed by a Cleared event.
Information events are typically one-time occurrences that are corrected by the module without a reset. They do not cause service degradation.
No craft action is required.
| ID | Event Name | Severity |
|---|---|---|
129 | LR_PING_FAIL | Critical |
The following description appears in the ViewRunner for Windows Event History View dialog box or the ViewRunner for HP OpenView Error Events Browser:
Module did not respond to the system monitorAn event of this severity causes loss of service for more than four subscribers. Here are two examples of this type of event:
In some cases, a module forces itself into a self-test based on the alarm condition. In other cases, the system controller (SC) module forces the alarmed module to reset. A module reset forces the module to be power cycled, self-tested, and reconfigured into the slot by the SC module.
Several alarm event conditions are cleared by a module reset. Look for the alarm event to clear within 1 minute. An alarm event is cleared when the SC module faceplate alarm LED changes from red to off.
In the ViewRunner management software, two actions show that an alarm event is cleared:
If the alarm event does not clear:
Step 1 Remove and reinsert the module. This forces a module to reset if neither the module nor the SC module could force a reset. A module reset usually clears all alarm conditions.
Step 2 Observe the SC module alarm LED or the ViewRunner ejector tabs to see if the alarm condition returns. If the previous problem persists, the condition will probably reoccur within 1 minute.
Step 3 If the alarm condition persists, replace the module.
Posted: Tue Nov 16 15:43:54 PST 1999
Copyright 1989-1999©Cisco Systems Inc.