http://permalink.gmane.org/gmane.comp.hardware.freeipmi.devel hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.hardware.freeipmi.devel/421 <pre>Just FYI, the web site (https://www.gnu.org/software/freeipmi/) hasn't been updated to include this release. -Rob -----Original Message----- From: freeipmi-users-bounces+swindell=broadcom.com-mXXj517/zsQ&lt; at &gt;public.gmane.org [mailto:freeipmi-users-bounces+swindell=broadcom.com-mXXj517/zsQ&lt; at &gt;public.gmane.org] On Behalf Of Albert Chu Sent: Monday, April 29, 2013 1:16 PM To: freeipmi-announce-mXXj517/zsQ&lt; at &gt;public.gmane.org; freeipmi-users-mXXj517/zsQ&lt; at &gt;public.gmane.org; freeipmi-devel-mXXj517/zsQ&lt; at &gt;public.gmane.org Subject: [Freeipmi-users] FreeIPMI 1.2.6 Released http://ftp.gnu.org/gnu/freeipmi/freeipmi-1.2.6.tar.gz FreeIPMI 1.2.6 - 04/29/13 ------------------------- o Support HP Proliant DL160 G8 OEM sensors. o Support Supermicro X9SCM-iiF OEM sensors and events. o Support output of temperature sampling period to ipmi-dcmi. o Clarify error message when SOL session cannot be stolen in ipmiconsole/libipmiconsole. o Fix dcmi rolling average time period output error o Fix ipmi-dcmi output errors with --get-dcmi-sensor-</pre> Rob Swindell 2013-05-14T22:00:16 http://permalink.gmane.org/gmane.comp.hardware.freeipmi.devel/420 <pre>Yes, the managed system's year was set wrong &lt;blush&gt;. :-) -Rob -----Original Message----- From: freeipmi-devel-bounces+swindell=broadcom.com-mXXj517/zsQ&lt; at &gt;public.gmane.org [mailto:freeipmi-devel-bounces+swindell=broadcom.com-mXXj517/zsQ&lt; at &gt;public.gmane.org] On Behalf Of Rob Swindell Sent: Thursday, May 09, 2013 7:47 PM To: freeipmi-devel-mXXj517/zsQ&lt; at &gt;public.gmane.org Subject: Re: [Freeipmi-devel] [bug #38798] timestamps are interpretted as UTC rather than localtime, violating IPMI 2.0 section 37 I can confirm that the SDR, SEL, and DCMI timestamps are now being interpreted as local time (corresponding to IPMI 2.0 section 37). For example, executed with both managed system and management console at May-9, 7:3x PM: SDR Repository Time : 05/09/2012 - 19:31:26 SEL Time : 05/09/2012 - 19:31:39 978 | May-09-2012 | 19:33:19 | PSU_REDUNDANCY | Power Unit | Non-redundant:Sufficient Resources from Redundant ; Event Data2 = F0h 979 | May-09-2012 | 19:33:19 | System Restart | System Boot Initiated </pre> Rob Swindell 2013-05-10T03:16:14 http://permalink.gmane.org/gmane.comp.hardware.freeipmi.devel/419 <pre>I can confirm that the SDR, SEL, and DCMI timestamps are now being interpreted as local time (corresponding to IPMI 2.0 section 37). For example, executed with both managed system and management console at May-9, 7:3x PM: SDR Repository Time : 05/09/2012 - 19:31:26 SEL Time : 05/09/2012 - 19:31:39 978 | May-09-2012 | 19:33:19 | PSU_REDUNDANCY | Power Unit | Non-redundant:Sufficient Resources from Redundant ; Event Data2 = F0h 979 | May-09-2012 | 19:33:19 | System Restart | System Boot Initiated | System Restart ; Chassis Control command 980 | May-09-2012 | 19:33:20 | SYS0_FAN_TACH | Fan | Lower Critical - going low ; Sensor Reading = 1280.00 RPM ; Threshold = 1792.00 RPM Power Statistics for Rolling Average Time Period 0 Seconds Current Power : 252 Watts Minimum Power over sampling duration : 22 watts Maximum Power over sampling duration : 264 watts Average Power over sampling duration : 181 watts Time Stamp </pre> Rob Swindell 2013-05-10T02:47:09 http://permalink.gmane.org/gmane.comp.hardware.freeipmi.devel/418 <pre>Update of bug #38798 (project freeipmi): Open/Closed: Open =&gt; Closed _______________________________________________________ Reply to this item at: &lt;http://savannah.gnu.org/bugs/?38798&gt; _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ </pre> Albert Chu 2013-05-09T17:10:05 http://permalink.gmane.org/gmane.comp.hardware.freeipmi.devel/417 <pre>Doh! Thanks. Fixed upstream. Al On Thu, 2013-05-09 at 01:58 +0000, Rob Swindell wrote: </pre> Albert Chu 2013-05-09T17:09:42 http://permalink.gmane.org/gmane.comp.hardware.freeipmi.devel/416 <pre>Update of bug #38811 (project freeipmi): Open/Closed: Open =&gt; Closed _______________________________________________________ Reply to this item at: &lt;http://savannah.gnu.org/bugs/?38811&gt; _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ </pre> Albert Chu 2013-05-09T15:23:56 http://permalink.gmane.org/gmane.comp.hardware.freeipmi.devel/415 <pre>Follow-up Comment #6, bug #38811 (project freeipmi): Latest fix appears to work. Below is a snippet of the output: FRU Inventory Device: CPU 1 DIMM 1 (ID 70h) FRU DRAM Device Type: DDR3 SDRAM FRU Total SDRAM Capacity : 2 Gb FRU Memory Banks : 8 Banks FRU Module 1.5 V Nominal Voltage : Operable FRU Module 1.35 V Nominal Voltage : Not Operable FRU Module 1.25 V Nominal Voltage : Not Operable FRU SDRAM Device Width : 4 bits FRU Number of Ranks : 1 FRU Primary Bus Width : 64 bits FRU Total Memory Capacity : 4096 GB FRU Module Manufacturer : Samsung FRU Module Manufacturing Date : Year 2011 Week 52 FRU Module Serial Number : 87B02B39 FRU Module Part Number : M393B5270DH0-CH9 FRU DRAM Manufacturer : Samsung _______________________________________________________ Reply to this item at: &lt;http://savannah.gnu.org/bugs/?38811&gt; _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ </pre> Michael Winiarski 2013-05-09T12:56:54 http://permalink.gmane.org/gmane.comp.hardware.freeipmi.devel/414 <pre>$ bmc-device/bmc-device --get-sel-time-utc-offset SEL Time : -420 minutes I think you want that to say "SEL UTC Offset" instead of "SEL Time" there. -Rob -----Original Message----- From: Albert Chu [mailto:INVALID.NOREPLY-mXXj517/zsQ&lt; at &gt;public.gmane.org] Sent: Wednesday, May 08, 2013 10:30 AM To: Albert Chu; Rob Swindell; freeipmi-devel-mXXj517/zsQ&lt; at &gt;public.gmane.org Subject: [bug #38798] timestamps are interpretted as UTC rather than localtime, violating IPMI 2.0 section 37 Follow-up Comment #3, bug #38798 (project freeipmi): I've updated the trunk w/ what I believe to be the right fixes. Included are 3 new options in all appropriate tools (i.e. ipmi-sel, bmc-device, etc.). They are --utc-to-localtime, --localtime-to-utc, and --utc-offset. They do about what they sound like, more info can be found in the manpages. _______________________________________________________ Reply to this item at: &lt;http://savannah.gnu.org/bugs/?38798&gt; _______________________________________________ Message sent v</pre> Rob Swindell 2013-05-09T01:58:21 http://permalink.gmane.org/gmane.comp.hardware.freeipmi.devel/413 <pre>Follow-up Comment #7, bug #38781 (project freeipmi): I agree that it's legacy enough that it may not be worth keeping around. I looked around at other open source IPMI projects and found that both ipmitool and openipmi do not do the pad (ipmiutil does though). I'll remove it for FreeIPMI 1.3.1. _______________________________________________________ Reply to this item at: &lt;http://savannah.gnu.org/bugs/?38781&gt; _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ </pre> Albert Chu 2013-05-08T23:11:10 http://permalink.gmane.org/gmane.comp.hardware.freeipmi.devel/412 <pre>Follow-up Comment #5, bug #38811 (project freeipmi): Thanks for the debug info, I was able to find a lot of issues with it. I think it should work now, could you give it another shot. _______________________________________________________ Reply to this item at: &lt;http://savannah.gnu.org/bugs/?38811&gt; _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ </pre> Albert Chu 2013-05-08T20:09:19 http://permalink.gmane.org/gmane.comp.hardware.freeipmi.devel/411 <pre>Follow-up Comment #3, bug #38798 (project freeipmi): I've updated the trunk w/ what I believe to be the right fixes. Included are 3 new options in all appropriate tools (i.e. ipmi-sel, bmc-device, etc.). They are --utc-to-localtime, --localtime-to-utc, and --utc-offset. They do about what they sound like, more info can be found in the manpages. _______________________________________________________ Reply to this item at: &lt;http://savannah.gnu.org/bugs/?38798&gt; _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ </pre> Albert Chu 2013-05-08T17:29:38 http://permalink.gmane.org/gmane.comp.hardware.freeipmi.devel/410 <pre>Follow-up Comment #4, bug #38811 (project freeipmi): Rebuilt ipmi-fru from the latest source repo. Looks like there is still a problem. Prior output (abbreviated): FRU Inventory Device: CPU 1 DIMM 1 (ID 70h) FRU Error: common header checksum invalid New output (abbreviated): FRU Inventory Device: CPU 1 DIMM 1 (ID 70h) fiid_template_block_len_bytes: Invalid argument Using the --debug option, this is the abbreviated debug output that I think is associated with the DIMM: 16.110.181.251: ===================================================== 16.110.181.251: IPMI 2.0 Read FRU Data Response 16.110.181.251: ===================================================== 16.110.181.251: RMCP Header: 16.110.181.251: ------------ 16.110.181.251: [ 6h] = version[ 8b] 16.110.181.251: [ 0h] = reserved[ 8b] 16.110.181.251: [ FFh] = sequence_number[ 8b] 16.110.181.251: [ 7h] = message_class.class[ 5b] 16.110.181.251: [ 0h] = message_class.reserved[ 2b] 16.</pre> Michael Winiarski 2013-05-08T14:36:07 http://permalink.gmane.org/gmane.comp.hardware.freeipmi.devel/409 <pre>Follow-up Comment #6, bug #38781 (project freeipmi): Just so you are aware, the still-existing code in ipmi_lan_sendto() is still incorrect for IPMI 1.5 compatibility: /* Note from Table 12-8, RMCP Packet for IPMI via Ethernet footnote Some LAN adapter chips may have a problem where packets of overall lengths 56, 84, 112, 128, or 156 are not handled correctly. The PAD byte is added as necessary to avoid these overall lengths. Remote console software must use the PAD byte when formatting packets to any 10/100 Ethernet device that accepts RMCP packets. -- Anand Babu */ _len = len; if (_len == 56 || _len == 84 || _len == 112 || _len == 128 || _len == 156) pad_len += IPMI_LAN_PKT_PAD_SIZE; Note the words "overall length" are used here in the comment (and in the specification), yet the length value being compared here is only the UDP payload length (*not* the "overall length"). If you really want this code to be correct, you would need to calcula</pre> Rob Swindell 2013-05-07T23:51:20 http://permalink.gmane.org/gmane.comp.hardware.freeipmi.devel/408 <pre>Update of patch #8043 (project freeipmi): Open/Closed: Open =&gt; Closed _______________________________________________________ Follow-up Comment #1: Applied, it'll be in the next release of FreeIPMI. _______________________________________________________ Reply to this item at: &lt;http://savannah.gnu.org/patch/?8043&gt; _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ </pre> Albert Chu 2013-05-06T23:21:10 http://permalink.gmane.org/gmane.comp.hardware.freeipmi.devel/407 <pre>Update of task #12587 (project freeipmi): Open/Closed: Open =&gt; Closed _______________________________________________________ Follow-up Comment #1: Will be in FreeIPMI 1.3.1. _______________________________________________________ Reply to this item at: &lt;http://savannah.gnu.org/task/?12587&gt; _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ </pre> Albert Chu 2013-05-06T18:20:35 http://permalink.gmane.org/gmane.comp.hardware.freeipmi.devel/406 <pre>URL: &lt;http://savannah.gnu.org/patch/?8043&gt; Summary: update deprecated autoconf macros Project: GNU FreeIPMI Submitted by: pva0xd Submitted on: Пнд 06 Май 2013 16:35:04 Category: None Priority: 5 - Normal Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any _______________________________________________________ Details: Hi, with automake 1.13 AM_CONFIG_HEADER macros is deprecated and in 1.14 it will be removed. Patch in attachment fixes this issue, please, apply. http://www.flameeyes.eu/autotools-mythbuster/forwardporting/automake.html _______________________________________________________ File Attachments: ------------------------------------------------------- Date: Пнд 06 Май 2013 16:35:04 Name: freeipmi-1.2.6-update-deprecated-macros.patch Size: 372B </pre> Peter Volkov 2013-05-06T16:35:05 http://permalink.gmane.org/gmane.comp.hardware.freeipmi.devel/405 <pre>Follow-up Comment #3, bug #38811 (project freeipmi): I've added support and the code is now in the FreeIPMI trunk. Unfortunately, I have no motherboards to test against, so I'm just assuming the code works. Could you give it a shot? svn co svn://svn.savannah.gnu.org/freeipmi/trunk freeipmi cd freeipmi ./autogen.sh ./configure make ipmi-fru/ipmi-fru If the autogen.sh fails, e-mail me privately and I can send you a tar.gz _______________________________________________________ Reply to this item at: &lt;http://savannah.gnu.org/bugs/?38811&gt; _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ </pre> Albert Chu 2013-05-04T00:32:07 http://permalink.gmane.org/gmane.comp.hardware.freeipmi.devel/404 <pre>Update of bug #38866 (project freeipmi): Open/Closed: Open =&gt; Closed _______________________________________________________ Reply to this item at: &lt;http://savannah.gnu.org/bugs/?38866&gt; _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ </pre> Albert Chu 2013-05-02T21:49:25 http://permalink.gmane.org/gmane.comp.hardware.freeipmi.devel/403 <pre>You're right, I guess I was looking in the wrong branch. I'll assume this closed now. Thanks. Al On Thu, 2013-05-02 at 21:37 +0000, Rob Swindell wrote: </pre> Albert Chu 2013-05-02T21:49:18 http://permalink.gmane.org/gmane.comp.hardware.freeipmi.devel/402 <pre>This code only exists in the current svn trunk (it's not in 1.2.6). No emergency. -Rob -----Original Message----- From: Albert Chu [mailto:INVALID.NOREPLY-mXXj517/zsQ&lt; at &gt;public.gmane.org] Sent: Thursday, May 02, 2013 8:06 AM To: Albert Chu; Rob Swindell; freeipmi-devel-mXXj517/zsQ&lt; at &gt;public.gmane.org Subject: [bug #38866] buffer overrun in _output_date() from sel/ipmi-sel-string.c:675 Follow-up Comment #1, bug #38866 (project freeipmi): Thanks for the catch. Is this occurring regularly for you w/ 1.2.6? Or has it always been around? Just wondering if I need to do an emergency 1.2.7 release. _______________________________________________________ Reply to this item at: &lt;http://savannah.gnu.org/bugs/?38866&gt; _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ </pre> Rob Swindell 2013-05-02T21:37:24 http://permalink.gmane.org/gmane.comp.hardware.freeipmi.devel/401 <pre> I don't think that's the case? localtime_r() and gmtime_r() assume input is UTC time. gmtime_r() only converts the inputted timestamp into the broken down time (struct tm)? I've been actually trying to figure out the best/most portable/thread safe way to convert from a localtime to UTC time and haven't quite figured it out. One developer in my group said I may need to muck w/ the timezone fields within 'struct tm', which seems scary. Mucking w/ the TZ environment variable is (AFAIK) not thread safe. I'm thinking manual calculation is probably the most safe/portable (i.e. calculate the difference between the gmtime &amp; localtime results and adjust appropriately). This was what I was going to have output as default. Yup, this was going to be my --assume-time-utc like option. I need to look on my systems and see how many support the get/set SEL UTC time commands. If very few do, I think that implementing something that tries to use it is perhaps fruitless. Or perhaps there would be option for the u</pre> Al Chu 2013-05-02T15:25:27 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.hardware.freeipmi.devel