HP MSA 1040 HP MSA Events Description Reference Guide (762785-001, March 2014) - Page 58

If that does not resolve the problem, the fault is probably in the enclosure midplane. Replace

Get HP MSA 1040 PDF manuals and user guides View all HP MSA 1040 manuals
Add to My Manuals
Save this manual to your list of manuals

Page 58 highlights

486 Warning A recovery process was initiated to prevent writing invalid data that may exist in the controller that logged this event. The controller that logged this event has detected (via information saved in the vdisk metadata) that it may contain outdated data that should not be written to the vdisks. The controller will log this event, restart the partner controller, wait 10 seconds, then kill itself. The partner controller will then unkill this controller and mirror the correct cache data to it. This procedure will, in most cases, allow all data to be correctly written without any loss of data and without writing any outdated data. Recommended actions • Wait at least 5 minutes for the automatic recovery process to complete. Then sign in and confirm that both controller modules are operational. (You can determine if the controllers are operational with the show redundancy-mode CLI command or the System Redundancy table in the System Overview panel of the SMU.) In most cases, the system will come back up and no action is required. • If both controller modules do not become operational in 5 minutes, see the recommended actions for event 485, which will be logged at approximately the same time. 487 Info. Historical performance statistics were reset. Recommended actions • No action is required. 494 Info. Reinitialization of a snap pool has completed. Recommended actions • No action is required. 495 Warning The algorithm for best-path routing selected the alternate path to the indicated disk because the I/O error count on the primary path reached its threshold. The controller that logs this event indicates which channel (path) has the problem. For example, if the B controller logs the problem, the problem is in the chain of cables and expansion modules connected to the B controller module. Recommended actions • If this event is consistently logged for only one disk in an enclosure, perform the following actions: • Replace the disk. • If that does not resolve the problem, the fault is probably in the enclosure midplane. Replace the chassis-and-midplane FRU for the indicated enclosure. • If this event is logged for more than one disk in an enclosure or disks in multiple enclosures, perform the following actions: • Check for disconnected SAS cables in the bad path. If no cables are disconnected, replace the cable connecting to the ingress port in the most-upstream enclosure with reported failures. If that does not resolve the problem, replace other cables in the bad path, one at a time until the problem is resolved. • If that does not resolve the problem, replace the expansion modules that are in the bad path. Begin with the most-upstream module that is in an enclosure with reported failures. If that does not resolve the problem, replace other expansion modules (and the controller module) upstream of the affected enclosure(s), one at a time until the problem is resolved. 58 Event descriptions

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
  • 44
  • 45
  • 46
  • 47
  • 48
  • 49
  • 50
  • 51
  • 52
  • 53
  • 54
  • 55
  • 56
  • 57
  • 58
  • 59
  • 60
  • 61
  • 62
  • 63
  • 64
  • 65
  • 66
  • 67
  • 68
  • 69
  • 70
  • 71
  • 72
  • 73
  • 74
  • 75
  • 76
  • 77
  • 78
  • 79
  • 80
58
Event descriptions
486
Warning
A recovery process was initiated to prevent writing invalid data that may exist in the controller that logged
this event.
The controller that logged this event has detected (via information saved in the vdisk metadata) that it may
contain outdated data that should not be written to the vdisks. The controller will log this event, restart the
partner controller, wait 10 seconds, then kill itself. The partner controller will then unkill this controller and
mirror the correct cache data to it. This procedure will, in most cases, allow all data to be correctly written
without any loss of data and without writing any outdated data.
Recommended actions
•
Wait at least 5 minutes for the automatic recovery process to complete. Then sign in and confirm that
both controller modules are operational. (You can determine if the controllers are operational with the
show redundancy-mode
CLI command or the System Redundancy table in the System Overview
panel of the SMU.) In most cases, the system will come back up and no action is required.
•
If both controller modules do not become operational in 5 minutes, see the recommended actions for
event 485, which will be logged at approximately the same time.
487
Info.
Historical performance statistics were reset.
Recommended actions
•
No action is required.
494
Info.
Reinitialization of a snap pool has completed.
Recommended actions
•
No action is required.
495
Warning
The algorithm for best-path routing selected the alternate path to the indicated disk because the I/O error
count on the primary path reached its threshold.
The controller that logs this event indicates which channel (path) has the problem. For example, if the B
controller logs the problem, the problem is in the chain of cables and expansion modules connected to the
B controller module.
Recommended actions
•
If this event is consistently logged for only one disk in an enclosure, perform the following actions:
•
Replace the disk.
•
If that does not resolve the problem, the fault is probably in the enclosure midplane. Replace the
chassis-and-midplane FRU for the indicated enclosure.
•
If this event is logged for more than one disk in an enclosure or disks in multiple enclosures, perform
the following actions:
•
Check for disconnected SAS cables in the bad path. If no cables are disconnected, replace the
cable connecting to the ingress port in the most-upstream enclosure with reported failures. If that
does not resolve the problem, replace other cables in the bad path, one at a time until the problem
is resolved.
•
If that does not resolve the problem, replace the expansion modules that are in the bad path. Begin
with the most-upstream module that is in an enclosure with reported failures. If that does not resolve
the problem, replace other expansion modules (and the controller module) upstream of the affected
enclosure(s), one at a time until the problem is resolved.