I will give it a try today. Thanks,
/jonathan On Thu, May 15, 2008 at 1:18 AM, Renier Morales <[EMAIL PROTECTED]> wrote: > > 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 > > ------------------------------------------------------------------------- > 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
