Re: [Openhpi-devel] AMC Not Hotswap-able

[Peter P. <pet...@en...>]

Hi Jason,

=20

   >> Since the AMC card is domiciled directly in the blade

=20

Ideally, you don't want to remove the blade because it'll bring down

any processing.  Yes, this is not a good option.

=20

   >> never raise an event to the daemon

=20

If the AMC Card is not inserted into the Blade when the Blade is

initiallly inserted, then the AMC Card's RDRs obviously cannot be

discovered.  However, once the AMC Card is inserted, and an

event generated, the ipmidirect code complains about an unknown

SDR and does not send the event up to the daemon.

=20

=20

   >> could call saHpiDiscover()

=20

My understanding of saHpiDiscover() is that it'll wake up the

    event thread

    discovery thread

making things run FASTER, however, I do no see where it causes

the AMC RDRs to get populated.  That appears to only happen when

the Blade on which the AMCs are populated is discovered.

=20

Peter P

=20

________________________________

From: ope...@li...
[mailto:ope...@li...] On Behalf Of Jason
Barrett
Sent: Wednesday, January 16, 2008 11:21 AM
To: ope...@li...
Subject: Re: [Openhpi-devel] AMC Not Hotswap-able

=20

Good morning,

=20

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.

=20

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.

=20

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)?

=20

Thanks,

Jason

=20

________________________________

From: ope...@li...
[mailto:ope...@li...] On Behalf Of Peter
Pothier
Sent: Wednesday, January 16, 2008 10:47 AM
To: ope...@li...
Subject: [Openhpi-devel] AMC Not Hotswap-able

=20

Hi,

=20

Using OpenHPI 2.10.1, AMC cards appear to be non-hotswap-able.

Bugs

=20

     #1868725     AMC not recognized if inserted after Discovery
complete

     #1794820     Inventory RDRs no longer visible after Hotswap AMC

=20

describe a couple of ways AMC cards fail when inserted and/or extracted.

=20

=20

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. =20

=20

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.

=20

=20

>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.

=20

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.

=20

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.

=20

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?

=20

=20

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.

=20

Is my understanding even correct or am I missing something?

=20

Thank You,

=20

Peter Pothier

=20

------------------------------------------------=20
Peter Pothier
Enea=20
One Tara Boulevard, Suite 404
Nashua, NH 03060
Direct: +1 603 888 7252=20
Fax: +1 603 888 6136
pet...@en... <mailto:pet...@en...> =20
www.enea.com
------------------------------------------------=20
Enea - Embedded for Leaders
------------------------------------------------=20

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.

=20