Oh my, those old Intel chassis... I would know by heart for sure on a Pigeon Point ShMM. I think I have access to one of those Intel chassis, I will see what I can do.
On PPS ShMM you can modify the threshold values for a sensor, change it so that the current value of the sensor crosses the new "fake" threshold, you should end up with an alarm, who knows with that old chassis ;) Regards, /jonathan On Wed, May 14, 2008 at 7:02 AM, Ganesha, Raghavendra Pandimakki <[EMAIL PROTECTED]> wrote: > 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 > ------------------------------------------------------------------------- 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
