On Mon, May 12, 2008 at 12:56 PM, Renier Morales <[EMAIL PROTECTED]> wrote:
>
> [EMAIL PROTECTED] wrote on 05/09/2008 07:01:38 AM:
>
>
>  > Hello Reneir,
>  >
>  > This regarding the bug 1794430 (Avoid duplicate alarms and
>  > \\\"blank\\\" alarms from entering).
>  >
>  > This bug is not fixed in openhpi-2.11 branch.
>  > I would like to know whether this bug is getting fixed.
>  > If not, I can take it up and try to fix.
>  >
>  > I'm analysing the bug and could able to make some progress.
>  >
>  > I could able to find the root cause of 'blank' alarms.
>  >
>  > The oh_add_alarm (openhpid/alarm.c +124) is causing the blank alarms
>  > to be put into the file.
>  > The oh_add_alarm is called by oh_detect_oem_event_alarm function
>  > (openhpid/alarm.c +352) for creating (allocating memory) the alarm
>  > structure and filling some of the fields.
>  > The same logic is also present in oh_detect_resource_event_alarm,
>  > oh_detect_sensor_event_alarm and oh_detect_resource_alarm functions.
>  > These functions calls oh_add_alarm with 3rd parameter set to 0
>  > (means save the alarm to file).
>  >
>  > Hence, whenever the oh_detect_oem_event_alarm (or
>  > oh_detect_resource_event_alarm or oh_detect_sensor_event_alarm or
>  > oh_detect_resource_alarm) gets executed, a blank alarm gets inserted
>  > into DAT file.
>
> Not quite right on the source of blank alarms. oh_add_alarm creates alarms
> whenever an alarm condition is detected. All the functions you mentioned are
> the entry points for the detection of alarm conditions.
> As far as I know, blank alarms get created when they are read from a
> previously persisted alarm. This is the area that needs focus. So alarms
> (non-blank) are being created fine, but if the daemon has been configured to
> presist alarms to disk and the daemon is later restarted, the domain DAT
> will show some blank alarms.
> Jonathan, correct me if I'm wrong here as I'm speaking from memory.
>

>From what I recall a "blank" alarm with description "xxxxx CRITICAL -
SENSOR 0/0 0x0" was getting created and also a duplicate was created,
except for the last state.

It was easy to reproduce with an ATCA Shelf Manager.

* Hook OpenHPI to a Shelf Manager with ipmidirect (enable alarm to disk)
* Simulate one alarm by playing with the threshold on the Shelf
Manager application to generate a threshold crossing.
* Look at the DAT with hpi_shell and exist.
* Kill openhpid and restart it
* Look back at the DAT with hpi_shell

You should now have the blank and duplicate. You can start all those
steps again and it will stack the blanks etc.

Regards,

/jonathan

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

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

Reply via email to