I kept looking through the alarm.c code and found more instances of the same issue.
Please, try the new attached patch. It supercedes the previous one.
--Renier
[EMAIL PROTECTED] wrote on 05/15/2008 01:18:47
AM:
>
> Jonathan or PGR,
> Try the attached patch and let me know if it solves the problem.
>
> Thanks,
>
> --Renier
> [EMAIL PROTECTED] wrote on 05/14/2008 06:48:39
AM:
>
> >
> > ________________________________________
> > From: [EMAIL PROTECTED] [openhpi-devel-
> > [EMAIL PROTECTED] On Behalf Of Renier Morales
> > [EMAIL PROTECTED]
> > Sent: Monday, May 12, 2008 10:26 PM
> > To: [email protected]
> > Subject: Re: [Openhpi-devel] Regarding bug 1794430
> >
> > [EMAIL PROTECTED] wrote on 05/09/2008
07:01:38 AM:
> >
> > >>
> > >> 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.
> >
> > [PGR] :
> > oh_add_alarm function creates the alarm structure if the second
> > parameter is NULL.
> > If the third parameter is 1, it means the alarm is read from DAT file.
> > Else if the third parameter is 0, it means that the alarm is needs
> > to be put into DAT file.
> >
> > If the second parameter is NULL and third parameter is 0. Then,
> > oh_add_alarm creates an blank alarm structure and writes the same
> > into the DAT file.
> >
> > I will try to explain with an example:
> > The oh_detect_oem_event_alarm function calls the oh_add_alarm with
> > second parameter as NULL and third parameter as zero (src/alarm.c
+352).
> > /* Severity is "alarming". Add/Create OEM alarm */
> > a = oh_add_alarm(d, NULL, 0);
> > if (!a) goto done;
> >
> > oh_add_alarm allocates memory for new alarm structure and copies the
> > passed alarm structure, if it is not NULL (src/alarm.c +157.
> > In this scenario, since the second parameter is NULL, blank alarm
> is created.
> > a = g_new0(SaHpiAlarmT, 1);
> > if (alarm) { /* Copy contents of optional alarm reference */
> > memcpy(a, alarm, sizeof(SaHpiAlarmT));
> > }
> >
> > oh_add_alarm fills up the generic fields of the alarm structure like
> > timestamp etc,.
> >
> > If the third parameter is zero, then oh_add_alarm puts the newly
> > created alarm into DAT file (src/alarm.c +182).
> > if (!fromfile) {
> > __update_dat(d);
> > param.type = OPENHPI_DAT_SAVE;
> > oh_get_global_param(¶m);
> > if (param.u.dat_save) {
> > char
dat_filepath[SAHPI_MAX_TEXT_BUFFER_LENGTH*2];
> > param.type = OPENHPI_VARPATH;
> > oh_get_global_param(¶m);
> > snprintf(dat_filepath,
> SAHPI_MAX_TEXT_BUFFER_LENGTH*2,
> > "%s/dat.%u", param.u.
> varpath, d->id);
> > oh_alarms_to_file(&d->dat, dat_filepath);
> > }
> > }
> >
> > In this case, the blank alarm is written into DAT file.
> >
> > The oh_detect_oem_event_alarm function fills the alarm structure
> > fields after the oh_add_alarm function returns successfully
(src/alarm.c +).
> > a->Severity = event->Severity;
> > a->AlarmCond.Type = SAHPI_STATUS_COND_TYPE_OEM;
> > oh_entity_path_lookup(event->Source, &a->AlarmCond.Entity);
> > a->AlarmCond.ResourceId = event->Source;
> > a->AlarmCond.Mid = event->EventDataUnion.OemEvent.MId;
> > memcpy(&a->AlarmCond.Data,
> > &event->EventDataUnion.OemEvent.OemEventData,
> > sizeof(SaHpiTextBufferT));
> >
> > The oh_add_alarm has written the blank alarm into DAT file before
> > all the alarm structure fields is populated.
> >
> > When openhpi daemon is restarted, it reads the blank (written
> > earlier) from the DAT file and puts into DAT.
> >
> > Regards,
> > Raghavendra PG
> >
> >
-------------------------------------------------------------------------
> > 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
> [attachment "oem_alarm.diff" deleted by Renier
> Morales/Poughkeepsie/IBM]
>
-------------------------------------------------------------------------
> 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
add_alarm.diff
Description: Binary data
------------------------------------------------------------------------- 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
