Good morning,
I read this post with great interest, since this is the situation I'm
working toward. We have an ATCA chassis with Intel blades and are in
the process of testing our hotswap software. Since the AMC card is
domiciled directly in the blade, instead of in a separate carrier blade,
extracting/inserting the blade is not an option.
Are you saying that an insertion with the ipmidirect plugin will never
raise an event to the daemon? Obviously that's a show-stopper. I was
thinking otherwise that maybe the client could call saHpiDiscover()
whenever any hotswap event occurred. Wasteful, yes, but it might force
the plugin to synchronize its RDRs with the daemon and get around this
issue.
Has anyone ever used OpenHPI with AMC cards anywhere? Would the 'ipmi'
plugin be preferable (although see my earlier emails to the list for
some issues I've had with that)?
Thanks,
Jason
________________________________
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Peter
Pothier
Sent: Wednesday, January 16, 2008 10:47 AM
To: [email protected]
Subject: [Openhpi-devel] AMC Not Hotswap-able
Hi,
Using OpenHPI 2.10.1, AMC cards appear to be non-hotswap-able.
Bugs
#1868725 AMC not recognized if inserted after Discovery
complete
#1794820 Inventory RDRs no longer visible after Hotswap AMC
describe a couple of ways AMC cards fail when inserted and/or extracted.
On an ATCA Chassis, there is a work-around. The Carrier card can be
extracted/inserted when replacing an AMC card. Yes, this does affect
other AMC cards on the same Carrier card, but it at least leaves the
rest of the system unaffected.
On a MicroTCA Chassis, I do not see any workarounds ... or at least any
workarounds that are limited in scope. The least intrusive way to get
around
these defects (that I know of) is to restart the OpenHPI Daemon so that
discovery can begin again and populate functions called including the
new
AMC Card. This will cause a temporary service outage for all other
resources.
>From what I can tell looking at the ipmidirect code, the main problem is
that
AMC RDRs are only populated and destroyed when the Carrier resource is
discovered or cleaned up. The AMC card, although a separate resource,
is
treated as part of the Carrier Card because it's FRUID is not zero.
Thus, when an AMC card is inserted into an empty slot, the ipmidirect
code cannot find the event's SDR because it was never populated when
the Carrier Card resource was initially discovered.
Alternatively, when an AMC card is discovered as part of the Carrier
Card
resource, and is then extracted, a NOT PRESENT event is sent up from the
plugin. All AMC RDRs are removed by the Daemon, but not by the
ipmidirect
plugin. When the AMC is re-inserted, only the Hotswap sensor RDR is
inserted
into the event (populate function is not called). Thus, only the
Hotswap
sensor RDR is re-added by the daemon. When HPI tries to subsequently
access
Inventory and other Sensors, they're not there because they've not been
re-added.
Because one type of AMC card could be replaced by a different type of
AMC card
with different RDRs, I would suspect the correct thing to do when
extracting
an AMC card is to destroy/clean up its RDRs in the ipmidirect plugin,
and then
re-populate when re-inserted?
Are there any plans to expand support for AMC Cards? Any plans to make
AMC Cards
more Hotswap-able? At the moment, it appears AMC Cards are not
hotswap-able.
Is my understanding even correct or am I missing something?
Thank You,
Peter Pothier
------------------------------------------------
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 SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Openhpi-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openhpi-devel
