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(&param);
>                 if (param.u.dat_save) {
>                         char 
dat_filepath[SAHPI_MAX_TEXT_BUFFER_LENGTH*2];
>                         param.type = OPENHPI_VARPATH;
>                         oh_get_global_param(&param);
>                         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
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

Reply via email to