In UCS CLI after issuing command ‘show cluster state‘ a warning is received on one of the chassis.
UCS-B # show cluster state Cluster Id: 0xf122a7f83dba11e0-0x9a4c123573c4f1c4
B: UP, PRIMARY A: UP, SUBORDINATE
HA READY Detailed state of the device selected for HA storage: Chassis 1, serial: FOX1234567A, state: active Chassis 2, serial: FOX1234567B, state: active Chassis 5, serial: FOX1234567C, state: active with errors
Fabric B, chassis-seeprom local IO failure: FOX1234567C READ_FAILED, error: TIMEOUT, error code: 10, error count: 7 Warning: there are pending SEEPROM errors on one or more devices, failover may not complete
In sam_techsupportinfo log you’ll see the following message Creation Time: 2012-10-12T01:12:21.217 ID: 2712562 Description: device FOX1234567C, error accessing shared-storage Affected Object: sys/mgmt-entity-B Trigger: Oper User: internal Cause: Device Shared Storage Io Error Code: E4196537
This is known Cisco Bug CSCtu17144 and here is what needs to be done
If the fault condition stays on or keeps being cleared and re-raised, try the following workarounds:
1. Reboot the IO module.
2. Remove and re-seat the IO module. Make sure the module is in contact with the backplane firmly.
I’ve had this problem couple times and resetting IO module was enough in both cases
Here is an interesting issue that I ran into with Cisco UCS blade.
I needed to move service profile from one blade to another. This is a process that should not give any problems but it did. Dissociation worked fine, but when I tried to associate the same profile with diferent blade I ran into problems.
Here is a problem that you can see when replacing or installing new DIMMs in UCS Blades.
Although the blade will boot but the newly installed DIMMs might show as disabled with invalid FRU error:
Error codes F0844 and F0502 are logged:
When you check inventory of the blade and go into Memoery you’ll see that Capacity and Clock are Unspecified.
SSH into UCSM IP.
Type: scope server x/y (where x is your chassis id and y is server id of the server that is having problems.) show memory (this list memory information of the blade) Server 1/1: Array 1: DIMM Location Presence Overall Status Type Capacity (MB) Clock
I think there is not much to explain here picture tell everything.
Had this setup for 4 months and have not broken a single prop. Had some minor crashes but nothing major.
But that does not mean that nobody is going to crash into you. Mid-air collision and here’s the picture:
I decided to get myself DJI NAZA for my quadcopter as almost everyone was raving about it.
I have self made MWC running Multiwii 2.0 on my quadcopter witch is running ok but I wanted better altitude hold and the videos in youtube show that NAZA is very good in doing that.
So I’ve got the following error on Cisco UCS IOmodule it came out of nowhere.
left IOM 4/1 (A) POST failure
So the fix could be very simple try reseating or resetting the IOmodule that is giving the problem.
Before you attempt to do that make sure that you the other IOmodule in the Chassis is working fine and all the blades in the chassis have other path available when the IOmodule is reseated. If you have only one IOmodule then you would need to power down the blades first.
Here I’ll show how to reset IOmodule from UCSM.
First select the IOmodule that is giving problems and click Reset IO Module
You’ll be prompted to confirm
You should see now that IOmodule is not reachable and one path for Chassis is down.
Also Critical errors and Warnings will be logged.
Wait for the IOmodule to comeback and the errors to clear.
If all is clear then monitor this module for couple weeks or so. If the same Error appears on IOmodule then call Cisco support to get the module replaced. I’ve seen where the error would reappear after 2-7 days. In that case call Cisco support to get IOmodule replaced.