Hi Jonathan, Thanks for the help and for the steps to re-produce the problem.
I'm trying to hard to generate the alarm in ATCA chassis. I've access to Intel ATCA chassis manager. If you know the steps to generate the alarms in ATCA chassis, please let me know. Regards, Raghavendra PG ________________________________________ From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Jonathan Fournier [EMAIL PROTECTED] Sent: Monday, May 12, 2008 11:01 PM To: [email protected] Subject: Re: [Openhpi-devel] Regarding bug 1794430 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 ------------------------------------------------------------------------- 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
