Hi Stephane,
Thanks for the response.
However, the basic question here is,
Before starting the openhpi, the LED will be in override state (which is
OFF), and after openhpi LAMP test, it is moving the LED to Local Control
State (which is ON).
In a broader perspective, after any test, the openhpi should restore the
initial state. However, the same is not happening in this case.
Hence, it looks like an issue with openhpi. Could you please confirm on the
same?
Regards,
Shridhar
_____
From: Martin, Stéphane [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 03, 2007 11:01 PM
To: [email protected]
Cc: Shridhar Sahukar
Subject: RE: [Openhpi-devel] Some clarification on LED States on AM4500
Hi Shridhar,
Here some clarification on LED behaviour on AM4500, SATA storage
AMC.
Normally, when power on the AMC, the state is local control and
ON. However, as soon as the Carrier AMC detect the AMC presence, the
Carrier AMC change the AMC LED state to override and remotely control the
AMC LED via IPMB-L base on Hot Swap state.
There is 2 ways to access the AMC LEDs, you can access it via the bridged
message (IPMI command send message on channel 7) from the IPMC to the
IPMB-L. This way you directly access the AMC LED API. However, the best
way to access AMC LED is to use the FRU Device ID and access the Carrier LED
API. This is the exact same PICMG LED API on the carrier but you must use
the correct FRU Device ID. This way the Carrier IPMC will remap your
command to the AMC and is aware of the new AMC LED state. If you do not go
this way, I suspect that there is LED command collision between the Carrier
AMC and your application. The AMC.0 is exactly to prevent this situation,
it avoid changing the override state from the IPMC API.
Also, there is a couple of AMC.0 req you should be aware for the LED test.
REQ 3.11 Upon insertion of the Module or power up of the Carrier, the BLUE
LED shall be
turned on as soon as possible.
REQ 3.15b Modules shall support the Lamp Test function for the BLUE LED as
defined in Section
3.2.5.6 FRU LED Control Commands of the PICMG 3.0 Specification.
REQ 3.16b The Carrier IPMC shall perform mapping of commands, sent by the
Shelf Manager or
other IPM Controllers to the FRUs representing Modules and addressing the
BLUE
LED, to the same commands directed to Module MMCs, using FRU ID 0. The
Carrier
shall track responses to these commands from the MMCs and forward them to
the
original initiators. This requirement does not apply to the command Set FRU
LED
State with LED function other than FBh (Lamp Test).
REQ 3.17 The Carrier IPMC shall reject any Set FRU LED State command sent
by the Shelf
Manager and other IPM Controllers to the FRUs representing Modules and
affecting the
BLUE LED, with LED Function different from FBh. The completion code returned
to
the initiator in that case shall be Invalid data field in Request (CCh).
_____
De : [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] De la part de Shridhar
Sahukar
Envoyé : 4 avril 2007 09:40
À : [email protected]
Objet : [Openhpi-devel] Some clarification on LED States on AM4500
Hi,
We are observing a strange behavior with openhpi 2.8, when used on an AMC
SATA Storage Device (AM4500). Below are the details:
ISSUE:
The issue we are observing is that, when the chassis is switched on,
initially the BLUE LED on the AMC will be in OFF state, and when we run
openhpi 2.8 on the card, by the end of the discovery process, the BLUE LED
will be turned ON and it will remain ON forever.
Our Findings:
We used clia command on the chassis manager to find out the various states
that the BLUE LED is going through, and below are our observations:
1. Normally when the chassis is rebooted, the LED State from the
getfruledstate command is:
82: FRU # 2, Led # 0 ("BLUE LED"):
Override LED State (current state): LED OFF
Local Control LED State: LED ON, color: BLUE
As shown in the above output, the Local control state of the LED is by
default ON. However it is overridden by the OFF state.
2. After we run openhpi 2.8, the getfruledstate output is as below:
82: FRU # 2, Led # 0 ("BLUE LED"):
Local Control LED State: LED ON, color: BLUE
Note that, now the LED is gone back to Local Control State, and the
override state is removed, which makes it glow forever.
Our Analysis:
1. We find that the Local Control State of this particular AMC SATA
Drive is ON by default, which is a deviation from any other LED status
(which are OFF by default)
2. It looks like the control software on the Device has set the
override state of the LED to OFF, and that is the reason we see it OFF on
boot up.
3. When we run openhpi discovery, during the LAMP test phase, it takes
the LED through various states, and finally gets it back to LOCAL CONTROL
STATE. In our case, since the local control state by default is ON, the LED
is turned on forever.
Queries:
1. On this particular device (AM4500), the default LOCAL Control State
being ON, does it have any specific meaning?
2. At the end of the LAMP test, openhpi moves the LED state back to
LOCAL Control State. I think this is based on the assumption that the
default state is OFF. But in this case, this assumption doesnt hold good.
So is this an issue to be addressed in Openhpi?
Your clarifications on the above questions will be much appreciated.
Regards,
Shridhar
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.446 / Virus Database: 268.18.25/743 - Release Date: 4/2/2007
4:24 PM
--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.446 / Virus Database: 268.18.25/745 - Release Date: 4/3/2007
12:48 PM
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.446 / Virus Database: 268.18.25/745 - Release Date: 4/3/2007
12:48 PM
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Openhpi-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openhpi-devel
