You can set it to a smaller number, maybe 5 seconds. It needs to be longer
than the longest WDT time plus IPMC reboot time.
Michael Thompson
Principal Engineer
Pentair Electronic Packaging
(Schroff & Electronic Solutions)
170 Commerce Drive
Warwick, RI 02886
Phone: +1 401-535-4869
FAX: +1 401-535-4951
Email: [EMAIL PROTECTED]
"Peter Pothier" <[EMAIL PROTECTED]>
08/24/2007 02:35 PM
To
<[EMAIL PROTECTED]>, <[email protected]>
cc
<[email protected]>,
<[EMAIL PROTECTED]>
Subject
RE: [Openhpi-devel] AMC Hotswap ipmidirect no RDRs
Thank you Michael for the information,
In fact, the M7_TIMEOUT is set to -1.
However, if I were to reduce this time, to say 30 seconds, there?s still a
window where I can extract
and insert the same module (within 30 seconds) and the M7 event, coupled
with the absence of an
M0 event, appears to leave ipmidirect and the daemon out of sync in
regards to RDRs.
Peter P
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Friday, August 24, 2007 2:25 PM
To: [email protected]
Cc: [email protected];
[EMAIL PROTECTED]; Peter Pothier
Subject: Re: [Openhpi-devel] AMC Hotswap ipmidirect no RDRs
If the shelf manager uses PPS firmware the default behavior is to leave
boards in the M7 state.
The problem might have been due to a crashed IPMC which will reset when
the WDT runs out and start talking to the shelf manager again. The shelf
manager really can't tell if the board was physically removed or the IPMC
is not talking.
When you plugged the board back in the shelf manager just though that the
IPMC was alive again. If you plugged a different board back into the
system the shelf manager will behave differently.
If the shelf manager uses PPS firmware then you can change the M7_TIMEOUT
setting in the /etc/shelfman.conf file to the number of seconds that you
want to wait for a board in the M7 state to start talking. If you change
the setting from -1 to 30, then 30 seconds after the board goes into the
M7 state it will transition to M0. Then when you plug the board back in
you will see the behavior that you expected.
# M7_TIMEOUT: This parameter specifies the maximum time interval (in
seconds)
# for a FRU to stay in M7 state. After the expiration of this time the
FRU
# is automatically transitioned into the M0 state. Default is -1 which
means
# "forever". Setting this parameter to 0 completely prevents FRUs
from
# going into the M7 state.
#
M7_TIMEOUT = -1
Michael Thompson
Principal Engineer
Pentair Electronic Packaging
(Schroff & Electronic Solutions)
170 Commerce Drive
Warwick, RI 02886
Phone: +1 401-535-4869
FAX: +1 401-535-4951
Email: [EMAIL PROTECTED]
"Peter Pothier" <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
08/24/2007 01:36 PM
Please respond to
[email protected]
To
"Peter Pothier" <[EMAIL PROTECTED]>,
<[email protected]>
cc
Subject
Re: [Openhpi-devel] AMC Hotswap ipmidirect no RDRs
Hi,
Using openHPI 2.8.1 and the ipmidirect plugin, this same issue appears to
also occur with an
ATCA Carrier Card, if the board is ejected too quickly (without waiting
for the LED to go Solid Blue).
When the board is ejected, a Communication Lost event is received. Here's
the transitions
M4 -> M5
M5 -> M7
M7 -> M2
M7 -> M1
M1 -> M2
M0 -> M1
M2 -> M3
M3 -> M4
M1 -> M2
M2 -> M3
M3 -> M4
The Communication Lost event causes a state of
SAHPI_HS_STATE_NOT_PRESENT
to be sent to the openhpi daemon, which therefore calls
oh_resource_remove()
However, the resource is not destroyed or cleaned up in the ipmidirect
plugin.
When the board is plugged back in, it only sends an event that contains
the Hotswap sensor.
None of the other resource data records are inserted into this event.
Thus, when the openhpi daemon
code calls
oh_resource_add()
it only learns about the one sensor. None of the other sensors, nor the
inventory are ever learned ...
Peter P
From: Peter Pothier
Sent: Friday, August 03, 2007 2:41 PM
To: [email protected]
Cc: Peter Pothier
Subject: AMC Hotswap ipmidirect no RDRs
Hi,
Using the ?ipmidirect? plugin (2.8.1), none of the AMC sensors or
inventory are visible (using hpitop)
after removing and re-inserting an AMC card
M4 -> M5.
M5 -> M6.
M6 -> M1.
M1 -> M0.
M0 -> M1.
M1 -> M2.
M2 -> M3.
M3 -> M4.
They do not disappear if the AMC module latch is merely opened and closed
without removing the AMC
M4 -> M5.
M5 -> M6.
M6 -> M1.
M1 -> M2.
M2 -> M3.
M3 -> M4.
Seems to be related to the transition to NOT PRESENT, which results in
calls to
oh_remove_resource()
oh_remove_rdr()
Trying to understand the ipmidirect code, it looks like all of the RDRs
are added to the Event message
at discovery time via the Populate() function. However, after the AMC is
pulled out of the system,
Cleanup()/Destroy() are not called because the AMC is not an MC (fruid !=
0). When the AMC is
re-inserted, it does not call Populate(). Instead, a (hotswap) sensor
Event Handler adds a single RDR
cIpmiSensor::HandleEvent()
rdrentry = oh_get_rdr_by_id(
res->Domain()->GetHandler()->rptcache, res->m_resource_id, m_record_id );
e->rdrs = g_slist_append(e->rdrs, g_memdup(rdrentry,
sizeof(SaHpiRdrT)));
I?m wondering if this is the same as Bug 1693130 (RDRs are not being
populated)?
If so, will the ipmidirect plugin be fixed as part of the solution?
Thank you,
Peter P
------------------------------------------------
Peter Pothier
Enea
One Tara Boulevard, Suite 404
Nashua, NH 03060
Direct: +1 603 888 7252
Fax: +1 603 888 6136
[EMAIL PROTECTED]
www.enea.com
------------------------------------------------
Enea - Embedded for Leaders
------------------------------------------------
This message, including attachments, is CONFIDENTIAL. It may also be
privileged or otherwise protected by law. If you received this email by
mistake please let us know by reply and then delete it from your system;
you should not copy it or disclose its contents to anyone. All messages
sent to and from Enea may be monitored to ensure compliance with internal
policies and to protect our business. Emails are not secure and cannot be
guaranteed to be error free as they can be intercepted, amended, lost or
destroyed, or contain viruses. The sender therefore does not accept
liability for any errors or omissions in the contents of this message,
which arise as a result of e-mail transmission. Anyone who communicates
with us by email accepts these risks.
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>
http://get.splunk.com/_______________________________________________
Openhpi-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openhpi-devel
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Openhpi-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openhpi-devel
