All posts by Andrius

UCS: waiting for flogi

Here is one very common error that you can see in  UCS Manager. I’ve observed it in multiple UCS firmware versions and all times it was cosmetic and had no impact.

On the blade you’ll see a major error similar to this:
Description: fc VIF 6 /R A-1095 down, reason: waiting for flogi
Cause: link-down
Code: F0283 

If you go to VIF paths on the blade you’ll see  error ‘waiting for flogi’ on vHBA that has the problem.

Now as I mentioned already this is most likely cosmetic issue. So first you need to verify that this is really the case. Continue reading UCS: waiting for flogi

UCS: Warning: there are pending SEEPROM errors on one or more devices, failover may not complete

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

UCS: configuration-failed; Code: F0170; connection-placement; There are not enough resources overall

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.

The first thing I noticed is Config Failure error in Status:

The Configuration error was:
connection-placement
There are not enough resources overall

Not enough vHBAs available
Not enough cNICs available Continue reading UCS: configuration-failed; Code: F0170; connection-placement; There are not enough resources overall

UCS: After installing or replacing DIMMs shown as disabled in UCS Manager(invalid FRU)

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

—- ———- —————- ———————— ———— ————- —– Continue reading UCS: After installing or replacing DIMMs shown as disabled in UCS Manager(invalid FRU)

DJI NAZA not arming with Turnigy Plush ESC(Fix/solution)

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.

Received NAZA this week connected it to existing setup, connected to PC to set it up properly.
After plugging in the battery NAZA does selftest and the light goes off. When I try to arm the motors nothing is happening. I though that I was doing  something wrong so checked everything again couple times. Still the same… Motors would not arm.
So I started reading through rcgroups and apparently it happens with some ESC .
http://www.rcgroups.com/forums/showthread.php?t=1610564
There is even a list created which ESCs work and which don’t.
https://docs.google.com/spreadsheet/ccc?key=0Au16aK6Q-0p0dENkdXVGVHJLRm5fRTFQdjBZbUhxZ3c&pli=1#gid=0

Unfortunately I am using Turnigy Plush 30A and these are the ones that most of the time are working.
On the label mine are ver 3.1 I’ve bought them sometime in July 2011.

Continue reading DJI NAZA not arming with Turnigy Plush ESC(Fix/solution)

IOM POST failure, Code: F0481

So I’ve got the following error on Cisco UCS IOmodule it came out of nowhere.

left IOM 4/1 (A) POST failure
Code: F0481

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.