Re: [Freeipmi-users] SDR cache not updated

[FRANK Michael]

Hi Al,

Thank you very much for your answer.

The timestamp looks curious:

SDR version                                       : 1.5
SDR record count                                  : 282
Free space remaining                              : 49139 bytes
Most recent addition timestamp                    : Post-Init 0 s
Most recent erase timestamp                       : Post-Init 0 s
Get SDR Repository Allocation Information Command : supported
Reserve SDR Repository Command                    : supported
Partial Add SDR Command                           : supported
Delete SDR Command                                : supported
Modal/non-modal SDR Repository Update operation   : non-Modal supported
SDR could not be written due to lack of space     : No
Number of possible allocation units               : 3836
Allocation unit size                              : 16 bytes
Number of free allocation units                   : 3071
Largest free block                                : 3071 allocation units
Maximum record size                               : 4 allocation units

I checked the logs of the BMC and no FW update was done since the server is in 
place and no sign of any other change: 

2020-09-19T01:21:06.445 ENET[CIM:ep1] IPv6-LinkLocal:HstName=BRGOIESX0012, 
IP@=fe80::3a68:ddff:fe26:6f6d ,Pref=64  .
2020-09-19T01:21:06.800 Inventory data collecting and processing complete for 
RAID subsystem, sequence number is 130.
2020-09-19T01:21:06.800 ENET[CIM:ep2] IP-Cfg:HstName=BRGOIESX0012, 
IP@=169.254.95.118 ,NetMsk=255.255.0.0, GW@=0.0.0.0  .
2020-09-19T01:21:07.540 Inventory data collecting and processing complete for 
RAID subsystem, sequence number is 131.
2020-09-19T01:21:07.540 ENET[CIM:ep2] IPv6-LinkLocal:HstName=BRGOIESX0012, 
IP@=fe80::3a68:ddff:fe26:6f6e ,Pref=64  .
2021-06-19T05:02:02.794 Numeric sensor Ambient Temp going high (upper 
non-critical) has asserted.
2021-06-19T07:53:52.442 Numeric sensor Ambient Temp going high (upper 
non-critical) has deasserted.

I will discuss the option of frequently flushing the SDR cache.

Thanks

Mike

-----Original Message-----
From: Al Chu <chu11@llnl.gov> 
Sent: Monday, July 19, 2021 7:11 PM
To: FRANK Michael <michael.frank@faurecia.com>; 'freeipmi-users@gnu.org' 
<freeipmi-users@gnu.org>
Subject: Re: [Freeipmi-users] SDR cache not updated

Hi Michael,

So a subtlety of --sdr-cache-recreate is that it will only update your SDR 
cache if its out of date.  My suspicion, is that your hardware SDR / firmware 
was updated, but the vendor did not update the SDR timestamps, thus FreeIPMI 
did not believe the SDR was out of date. 
(You can see these timestamps via ipmi-sensors -i).

Unfortunately the solution is to simply flush the sdr cache (--flush-
cache) and force its recreation.  The interval you want to do this is sort of 
up to you.

Perhaps you could script to check if the firmware version has changed and only 
force the --flush-cache when necessary?  You can see this via bmc-info, but 
this of course assumes the vendor bothered to update the firmware revision 
number.

Al

On Mon, 2021-07-19 at 16:23 +0000, FRANK Michael wrote:
> Hello,
> 
> we use ipmi-sensors with the option --sdr-cache-recreate In a script 
> which is scheduled every minute for monitoring purpose.
> On one of our sites we had a lot of false positive events on two 
> servers ( see attached logs).
> Finally, I found out that the SDR cache file was already 3 years old.
> After flushing the cache all sensors went back to normal. The only 
> thing was that 11 sensors left had been discovered.
> 
> My question is now how this option --sdr-cache-recreate is working and 
> what can I do to let ipmi-sensors automatically refresh the cache file 
> in case something changes on the remote end.
> I am worried about what happen if new FRUs are added. If the cache 
> file is not updated with new sensors, we miss the monitoring of newly 
> added things,
> 
> Any help is much appreciated
> 
> Michael FRANK
> Supervisor Global Monitoring Architecture Faurecia Clean Mobility T 
> +49 821 4103 420 ● M +49 171 9967 206 michael.frank@faurecia.com 
> Faurecia Emissions Control Technologies, Germany GmbH - 
> Biberbachstraße 9 – 86154 Augsburg – Germany
> 
> Sitz der Gesellschaft: Augsburg - Registergericht Augsburg HR B 20757
> Geschäftsführer: Yves Andres, Silke Krome, Soeren Peters Vorsitzender 
> des Aufsichtsrats: Mathias Miedreich
> 
> 
> 
> This electronic transmission (and any attachments thereto) is intended 
> solely for the use of the addressee(s). It may contain confidential or 
> legally privileged information. If you are not the intended recipient 
> of this message, you must delete it immediately and notify the sender. 
> Any unauthorized use or disclosure of this message is strictly 
> prohibited.  Faurecia does not guarantee the integrity of this 
> transmission and shall therefore never be liable if the message is 
> altered or falsified nor for any virus, interception or damage to your 
> system.
> 
> WARNING: This email violated LLNL's email security policy and has been 
> modified. If you would like a list of blocked file types or for more 
> information please see:
> 
> Blocked Email Extensions
> 
> An attachment free_ipmi.tgz  was removed from this document as it 
> constituted a security hazard. If you require this document, please 
> contact the sender and arrange an alternate means of receiving it.
> _______________________________________________
> Freeipmi-users mailing list
> Freeipmi-users@gnu.org
> https:///urldefense.us/v
> 3/__https://lists.gnu.org/mailman/listinfo/freeipmi-users__;!!G2kpM7uM
> -TzIFchu!il28AShgA_3e9-3O1mjJ4yThSSwsvyMoJVEk2MSSwbbIScwcrBqEUkGgpK0HS
> XOh$



This electronic transmission (and any attachments thereto) is intended solely 
for the use of the addressee(s). It may contain confidential or legally 
privileged information. If you are not the intended recipient of this message, 
you must delete it immediately and notify the sender. Any unauthorized use or 
disclosure of this message is strictly prohibited.  Faurecia does not guarantee 
the integrity of this transmission and shall therefore never be liable if the 
message is altered or falsified nor for any virus, interception or damage to 
your system.