Hi,
The simplest solution is to wait for the state to transition to Inactive
before pulling the card.
However, there's no guarantee users will do that.
I don't think the ipmidirect plugin and the daemon should get out of
sync in regards to RDRs.
I wonder if the HotSwap Event should be including a list of ALL RDRs,
similar to what's being
done in rdr->Populate()?
Peter P
________________________________
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Friday, August 24, 2007 2:39 PM
To: Peter Pothier
Cc: [email protected];
[EMAIL PROTECTED]
Subject: RE: [Openhpi-devel] AMC Hotswap ipmidirect no RDRs
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] <mailto:[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
