Well, I'm still thinking about it :).
My current thought is to do the following:
* Discover what the IPMI spec really means about these things and
implement that by default. I believe you are working on this now.
* Write hacks for existing systems that are wrong.
It's not pretty, but it's the best I can come up with. I don't think it
will be possible to implement something that works correctly for every
chassis out there.
-Corey
Chandrasekharapuram Venkateswaran-CVC008 wrote:
> Do you have any recommendation on how to resolve this ?
>
> Venkat
>
> -----Original Message-----
> From: Corey Minyard [mailto:[EMAIL PROTECTED]
> Sent: Friday, January 05, 2007 9:44 AM
> To: Chandrasekharapuram Venkateswaran-CVC008
> Cc: [EMAIL PROTECTED];
> [email protected]
> Subject: Re: [Openipmi-developer] openIPMI
>
> In reviewing the information on this and experimenting with various
> systems, I have come to the conclusion that presence is hopelessly
> broken for fielded IPMI systems and is very confusing in the details of
> how things work in the spec.
>
> For instance, there is the "ignore sensor if entity not present" bit.
> Theoretically, you should ignore the sensor for presence if the bit is
> *not* set (backwards from the logic currently in OpenIPMI). The theory
> being, if you do not ignore the sensor if the entity is not present,
> then the sensor works if the entity is not present and thus is not
> suitable for presence. However, that breaks presence for a whole bunch
> of things.
>
> I discovered that the "reading/state unavailable" bit in the "Get Sensor
> Reading" command has some presence meaning. I discovered this when
> looking at some weirdness (both false positives and false negatives,
> there was a presence sensor that had both the present and absent bits
> not set!). If that bit is set, then the reading is invalid. The text
> for that bit hints that the entity might not be present if the bit is
> set, and the sensor is probably useless for presence if the bit is set.
>
> However, trying this causes false negatives for fans that are not
> spinning, because that bit is also used for telling if the sensor cannot
> be read properly.
>
> So I'm not sure if the situation can be correctly resolved in fielded
> systems without writing custom code for each chassis type :-(.
>
> -Corey
>
> Corey Minyard wrote:
>
>> Thinking about this some more, I think I may have gotten the logic
>> backwards. If the sensors is not ignored when the entity is not
>> present, then it should be ignored for presence (as, presumably, the
>> sensor is alway there, even when the entity is not present).
>>
>> However, that change would almost certainly break a lot of things.
>>
>> -Corey
>>
>> Corey Minyard wrote:
>>
>>> This reply seems to have been lost, so I'll resend...
>>>
>>> That is a difficult question. That bit says "Ignore sensor if Entity
>>>
>
>
>>> is not present or disabled". If you should ignore it if the entity
>>> is not present, why would you use it to detect entity presence?
>>>
>>> I added this check as documented in the 2005-02-24 changelog entry:
>>>
>>> * lib/entity.c: Ignore controls and sensors for presence if they
>>> are supposed to be ignored when the entity is not present. I
>>> think I previously misunderstood this bit (not like it is well
>>> explained, anyway).
>>>
>>> IIRC, I was having trouble with false positives and after reviewing
>>> the use of this bit, it seemed best to do this. So I'm not quite
>>> sure what to do about this. It would be nice if we could ask the
>>> people who maintain the IPMI spec about this.
>>>
>>> -Corey
>>>
>>>
>>> Chandrasekharapuram Venkateswaran-CVC008 wrote:
>>>
>>>
>>>> I am currently trying to get openHPI and openIPMI installed and
>>>> working on HP DL360. I have all of the packages installed (openIPMI
>>>> 2.0.10, openHPI-2.6.3 along with hp-openIPMI driver).
>>>>
>>>> I am using the libipmi plugin. The IPMI driver is up and running
>>>> along with the openhpid daemon. When I use ipmitool to retrieve the
>>>> sensors I get all the sensors (about 28 of them). When I used the
>>>> openhpi clients (such as hpisensor etc), the count is 5. After
>>>> turning on the debugging in the ipmi plugin, here is what I
>>>>
> noticed...
>
>>>>
>>>> There are 28 entries of Entities ADDED (which matches with what
>>>> ipmitool returns). However, there are *ONLY* 5 entries of Entities
>>>> which are marked PRESENT.
>>>> During ipmi_discover_resources, events will be sent to the
>>>> infrastructure queue for *ONLY* the entities that are marked
>>>> *PRESENT*. Hence, hpisensor or any of the hpi clients or even for
>>>> that matter the apps that use SaHPI apis return only 5 as these are
>>>> the only ones that are inserted into the HPI data model.
>>>>
>>>> I started looking at the openIPMI code (mainly entity.c and
>>>> sensor.c) and noticed the following:
>>>>
>>>> 1) ent_detect_presence is called to detect the presence of the
>>>> entity (following the IPMI spec). If neither the Presence Sensor
>>>> exists nor the Presence Bit sensor is set,
>>>> detect_no_presence_sensor_presence is called to try and see if the
>>>> sensors (try_presence_sensors), controls(try_presence_controls)
>>>> detect something.
>>>>
>>>> 2) In try_presence_sensors, sensor_detect_send is called.
>>>>
>>>> 3) sensor_detect_send checks if ignore_if_no_entity bit is set in
>>>> the sensor SDR. If this bit is SET, we do not ping the sensor. If
>>>> the whole point is to detect the presence of the entity and probing
>>>> the sensor is required in order to do that - should we still be
>>>> checking this BIT ? I removed this check and now I am able to
>>>> retrieve all the sensors even with hpisensor client. But, want to
>>>> make sure that I am not missing something here...
>>>>
>>>> Thanks
>>>> Venkat
>>>> --------------------------------------------------------------------
>>>> ----
>>>>
>>>>
>>>>
>>>>
>>
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Openipmi-developer mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/openipmi-developer
>
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Openipmi-developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openipmi-developer
