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