Jonathan,
Did it went well with this patch?
--Renier
"Jonathan Fournier" <[EMAIL PROTECTED]> wrote on 05/15/2008
08:23:55 AM:
> 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
-------------------------------------------------------------------------
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
