Re: [Freeipmi-devel] Trouble w/ HP ProLiant and FreeIPMI (ipmi-sensors)
As an added note to other developers, I've added a few extra notes about the -v and -vv options in the HEAD ipmi-sensors manpage now too. Al On Wed, 2007-10-10 at 09:26 -0700, Al Chu wrote: > Hey Gregor, > > There is a sublety here that I added extra documentation for in the > FreeIPMI 0.5.0 manpage (I didn't backport to 0.4.X b/c didn't think it > was that important, but maybe I should have). The ipmi-sensors numbers > listed on the left are "record ids", not sensor numbers. If you use the > verbose options on ipmi-sensors (-v or -vv), you can find the sensor > numbers. As an example on my system: > > Record ID: 22 > Sensor Name: Fan5 > Group Name: Fan > Sensor Number: 18 > Event/Reading Type Code: 1h > > you can see the sensor number and record id don't match up. > > I'm not 100% why record ids were chosen for input/output over sensor > numbers in ipmi-sensors (the tool was originally created by others), but > if I had to guess for some reasons why: > > - some sensors don't have sensor numbers. I notice multiple sensors w/ > sensor number 0x00 in the ipmitool output below. I would guess those > sensors don't have a number so they just output 0x00. > > - record ids increase in value, while sensor numbers need not, so > outputting record ids looks nicer, maybe? The output order in ipmitool > also seems to be record id based, but they just output the sensor number > instead of the record id. > > As an FYI if you were wondering why sensors seem to be missing from > ipmi-sensors, our default output does not output every sensor by > default. Some are only retrievable via the verbose options. > > Hope that helps clarify things. > > Al > > On Wed, 2007-10-10 at 11:06 +0200, Gregor Dschung wrote: > > Hey Al, > > > > mmmh now, I'm really confused. I thought, the sensor-id has to be 8 > > bit long? > > > > Also I'm confused about the different sensor-ids I'm getting with > > ipmi-sensors (0.4.6.beta2) and `ipmitool sdr elist` (1.8.6). Sure, > > ipmitool is giving me the sensor id as Hex and ipmi-sensors as a decimal > > number... but the converted value should be the same? > > I would like to set up a PEF-Table, but for that, I'll need the right > > sensor-ids :-/ > > > > Example 1: > > > > p300slg01:/usr/local/src # ipmitool -H gtseval-ipmi -U ADMIN -a sdr > > elist all > > Password: > > Hewlett-Packard | 00h | ok | 0.0 | Dynamic MC @ 20h > > ACPI State | 20h | ok | 0.0 | S0/G0: working > > System Reset | 21h | ok | 0.0 | > > POST Error | 01h | ns | 0.0 | Disabled > > Memory ECC | 02h | ns | 0.0 | Disabled > > PCI Error| 03h | ns | 0.0 | Disabled > > Fan Error| 04h | ns | 0.0 | Disabled > > Watchdog | FEh | ns | 0.0 | Disabled > > CPU Fan 1| 31h | ok | 0.0 | 9592.33 RPM > > CPU Fan 2| 32h | ok | 0.0 | 10426.44 RPM > > CPU Fan 3| 33h | ok | 0.0 | 9992.01 RPM > > CPU Fan 4| 34h | ok | 0.0 | 10900.37 RPM > > CPU Fan 5| 35h | ok | 0.0 | 9592.33 RPM > > CPU Fan 6| 3Ch | ok | 0.0 | 10900.37 RPM > > CPU Fan 7| 3Dh | ok | 0.0 | 9992.01 RPM > > CPU Fan 8| 3Eh | ok | 0.0 | 10426.44 RPM > > CPU Fan 9| 3Fh | ok | 0.0 | 9592.33 RPM > > CPU Fan 10 | 40h | ok | 0.0 | 10426.44 RPM > > System Fan 1 | 41h | ok | 0.0 | 9992.01 RPM > > System Fan 2 | 42h | ok | 0.0 | 10900.37 RPM > > CPU0 Vcore | 3Ah | ok | 3.0 | 1.10 Volts > > CPU1 Vcore | 3Bh | ns | 3.1 | No Reading > > Standby 5V | 37h | ok | 0.0 | 4.97 Volts > > System 5V| 36h | ok | 0.0 | 4.85 Volts > > System 3.3V | 38h | ok | 0.0 | 3.23 Volts > > 3V CMOS Sense| 39h | ok | 0.0 | 3.03 Volts > > CPU0 Therm Diode | 43h | ns | 3.0 | Disabled > > CPU1 Therm Diode | 44h | ns | 3.1 | Disabled > > CPU0 ThermDiode2 | 52h | ns | 3.0 | Disabled > > CPU1 ThermDiode2 | 53h | ns | 3.1 | Disabled > > AMB Temp | 48h | ok | 0.0 | 29 degrees C > > MultiBit ECC ER | 4Ah | ok | 0.0 | State Deasserted > > VDD Power Fail | 4Ch | ok | 0.0 | State Deasserted > > Reset| 4Dh | ok | 0.0 | State Deasserted > > Identify | 4Eh | ok | 0.0 | State Deasserted > > NMI | 50h | ok | 0.0 | State Deasserted > > CPU0 Therm-Trip | 55h | ok | 3.0 | State Deasserted > > CPU1 Therm-Trip | 56h | ns | 3.1 | No Reading > > CPU0 IERR| 57h | ok | 3.0 | State Deasserted > > CPU1 IERR| 58h | ns | 3.1 | No Reading > > CPU0 Prochot | 59h | ok | 3.0 | Limit Not Exceeded > > CPU1 Prochot | 5Ah | ns | 3.1 | No Reading > > CPU0 SocketOcc | 5Bh | ok | 3.0 | Device Present > > CPU1 SocketOcc | 5Ch | ok | 3.1 | Device Absent > > CPU0 Dmn 0 Temp | 86h | ok | 3.0 | 45 degrees C > > CPU1 Dmn 0 Temp | 89h | ns | 3.1 | No Reading > > CPU0 Dmn 1 Temp | 8Ch | ok | 3.0 | 45 degrees C > > CPU1 Dmn 1 Temp | 8Fh | ns | 3.1 | No Reading > > FRU0 | 00h | ns | 0.0 | Logica
Re: [Freeipmi-devel] Trouble w/ HP ProLiant and FreeIPMI (ipmi-sensors)
Hey Gregor, There is a sublety here that I added extra documentation for in the FreeIPMI 0.5.0 manpage (I didn't backport to 0.4.X b/c didn't think it was that important, but maybe I should have). The ipmi-sensors numbers listed on the left are "record ids", not sensor numbers. If you use the verbose options on ipmi-sensors (-v or -vv), you can find the sensor numbers. As an example on my system: Record ID: 22 Sensor Name: Fan5 Group Name: Fan Sensor Number: 18 Event/Reading Type Code: 1h you can see the sensor number and record id don't match up. I'm not 100% why record ids were chosen for input/output over sensor numbers in ipmi-sensors (the tool was originally created by others), but if I had to guess for some reasons why: - some sensors don't have sensor numbers. I notice multiple sensors w/ sensor number 0x00 in the ipmitool output below. I would guess those sensors don't have a number so they just output 0x00. - record ids increase in value, while sensor numbers need not, so outputting record ids looks nicer, maybe? The output order in ipmitool also seems to be record id based, but they just output the sensor number instead of the record id. As an FYI if you were wondering why sensors seem to be missing from ipmi-sensors, our default output does not output every sensor by default. Some are only retrievable via the verbose options. Hope that helps clarify things. Al On Wed, 2007-10-10 at 11:06 +0200, Gregor Dschung wrote: > Hey Al, > > mmmh now, I'm really confused. I thought, the sensor-id has to be 8 > bit long? > > Also I'm confused about the different sensor-ids I'm getting with > ipmi-sensors (0.4.6.beta2) and `ipmitool sdr elist` (1.8.6). Sure, > ipmitool is giving me the sensor id as Hex and ipmi-sensors as a decimal > number... but the converted value should be the same? > I would like to set up a PEF-Table, but for that, I'll need the right > sensor-ids :-/ > > Example 1: > > p300slg01:/usr/local/src # ipmitool -H gtseval-ipmi -U ADMIN -a sdr > elist all > Password: > Hewlett-Packard | 00h | ok | 0.0 | Dynamic MC @ 20h > ACPI State | 20h | ok | 0.0 | S0/G0: working > System Reset | 21h | ok | 0.0 | > POST Error | 01h | ns | 0.0 | Disabled > Memory ECC | 02h | ns | 0.0 | Disabled > PCI Error| 03h | ns | 0.0 | Disabled > Fan Error| 04h | ns | 0.0 | Disabled > Watchdog | FEh | ns | 0.0 | Disabled > CPU Fan 1| 31h | ok | 0.0 | 9592.33 RPM > CPU Fan 2| 32h | ok | 0.0 | 10426.44 RPM > CPU Fan 3| 33h | ok | 0.0 | 9992.01 RPM > CPU Fan 4| 34h | ok | 0.0 | 10900.37 RPM > CPU Fan 5| 35h | ok | 0.0 | 9592.33 RPM > CPU Fan 6| 3Ch | ok | 0.0 | 10900.37 RPM > CPU Fan 7| 3Dh | ok | 0.0 | 9992.01 RPM > CPU Fan 8| 3Eh | ok | 0.0 | 10426.44 RPM > CPU Fan 9| 3Fh | ok | 0.0 | 9592.33 RPM > CPU Fan 10 | 40h | ok | 0.0 | 10426.44 RPM > System Fan 1 | 41h | ok | 0.0 | 9992.01 RPM > System Fan 2 | 42h | ok | 0.0 | 10900.37 RPM > CPU0 Vcore | 3Ah | ok | 3.0 | 1.10 Volts > CPU1 Vcore | 3Bh | ns | 3.1 | No Reading > Standby 5V | 37h | ok | 0.0 | 4.97 Volts > System 5V| 36h | ok | 0.0 | 4.85 Volts > System 3.3V | 38h | ok | 0.0 | 3.23 Volts > 3V CMOS Sense| 39h | ok | 0.0 | 3.03 Volts > CPU0 Therm Diode | 43h | ns | 3.0 | Disabled > CPU1 Therm Diode | 44h | ns | 3.1 | Disabled > CPU0 ThermDiode2 | 52h | ns | 3.0 | Disabled > CPU1 ThermDiode2 | 53h | ns | 3.1 | Disabled > AMB Temp | 48h | ok | 0.0 | 29 degrees C > MultiBit ECC ER | 4Ah | ok | 0.0 | State Deasserted > VDD Power Fail | 4Ch | ok | 0.0 | State Deasserted > Reset| 4Dh | ok | 0.0 | State Deasserted > Identify | 4Eh | ok | 0.0 | State Deasserted > NMI | 50h | ok | 0.0 | State Deasserted > CPU0 Therm-Trip | 55h | ok | 3.0 | State Deasserted > CPU1 Therm-Trip | 56h | ns | 3.1 | No Reading > CPU0 IERR| 57h | ok | 3.0 | State Deasserted > CPU1 IERR| 58h | ns | 3.1 | No Reading > CPU0 Prochot | 59h | ok | 3.0 | Limit Not Exceeded > CPU1 Prochot | 5Ah | ns | 3.1 | No Reading > CPU0 SocketOcc | 5Bh | ok | 3.0 | Device Present > CPU1 SocketOcc | 5Ch | ok | 3.1 | Device Absent > CPU0 Dmn 0 Temp | 86h | ok | 3.0 | 45 degrees C > CPU1 Dmn 0 Temp | 89h | ns | 3.1 | No Reading > CPU0 Dmn 1 Temp | 8Ch | ok | 3.0 | 45 degrees C > CPU1 Dmn 1 Temp | 8Fh | ns | 3.1 | No Reading > FRU0 | 00h | ns | 0.0 | Logical FRU @00h > -- > p300slg01:/usr/local/src # ipmi-sensors -h gtseval-ipmi -u ADMIN -P > Password: > 64: ACPI State (ACPI Power State): [S0/G0 "working"] > 112: System Reset (Module/Board): [OK] > 160: POST Error (System Firmware): [Unknown] > 208: Memory ECC (Memory): [Unknown] > 256: PCI Error (Critical Interrupt): [Unknown] > 304: Fan Error (Cooling Device): [Unknown] > 352: Watchdog (Watc
Re: [Freeipmi-devel] Trouble w/ HP ProLiant and FreeIPMI (ipmi-sensors)
Hey Gregor, I finally found it. The sdr you sent me was the key to figuring it out. The OEM data in your sdr cache was quite large (55 bytes) which triggered a buffer overflow. The length of the buffer was actually handled properly in the code, except the uint8_t buffer was casted into a unsigned int * buffer. Obviously, when the oem data is small (< 14 bytes) there's no problem. It only occurs when we hit large oem data sizes. Thanks for working on this with me so much. I'll send you a new test.tar.gz later on in a private e-mail. Al On Tue, 2007-10-09 at 17:25 +0200, Gregor Dschung wrote: > Hey Al, > > here is the sdr-cache. 'sdr-cache-p300slg01.10.136.17.128' is the file > for gtseval-ipmi, 'sdr-cache-p300slg01.10.136.17.170' is an other cache > file from a call of ipmi-sensors which works fine. > > I'm using FreeIPMI on a system with SUSE 10.1. > - > p300slg01:/usr/local/src # uname -a > Linux p300slg01 2.6.16.27-0.9-smp #1 SMP Tue Feb 13 09:35:18 UTC 2007 > i686 i686 i386 GNU/Linux > - > > In your test4-code, I had to change the following lines to compile w/o > errors: > common/src/pstdout.c > -243: fprintf(stderr, "Default stack size = %li bytes \n", mystacksize); > +243: fprintf(stderr, "Default stack size = %li bytes \n", > (long)mystacksize); > +501: va_list vacpy; > > - > > I've tested FreeIPMI locally again. I was wrong, it crashes, too. I > guess, I was confused with IPMItool, which runs fine locally but gives > warnings over the network. Don't know whether it helps you: > Locally: > [EMAIL PROTECTED]:~/ipmi/usr/bin> ./ipmitool -I open sensor > ACPI State | 0x1| discrete | 0x0180| na| > na| na| na| na| na > System Reset | 0x0| discrete | 0x0080| na| > na| na| na| na| na > POST Error | na | discrete | na| na| > na| na| na| na| na > Memory ECC | na | discrete | na| na| > na| na| na| na| na > PCI Error| na | discrete | na| na| > na| na| na| na| na > Fan Error| na | discrete | na| na| > na| na| na| na| na > Watchdog | na | discrete | na| na| > na| na| na| na| na > CPU Fan 1| 9992.006 | RPM| ok| na| > na| na| 3996.803 | 3475.480 | na > CPU Fan 2| 10426.441 | RPM| ok| na| > na| na| 3996.803 | 3475.480 | na > CPU Fan 3| 9992.006 | RPM| ok| na| > na| na| 3996.803 | 3475.480 | na > CPU Fan 4| 10426.441 | RPM| ok| na| > na| na| 3996.803 | 3475.480 | na > CPU Fan 5| 9223.391 | RPM| ok| na| > na| na| 3996.803 | 3475.480 | na > CPU Fan 6| 10900.371 | RPM| ok| na| > na| na| 3996.803 | 3475.480 | na > CPU Fan 7| 9992.006 | RPM| ok| na| > na| na| 3996.803 | 3475.480 | na > CPU Fan 8| 10900.371 | RPM| ok| na| > na| na| 3996.803 | 3475.480 | na > CPU Fan 9| 9992.006 | RPM| ok| na| > na| na| 3996.803 | 3475.480 | na > CPU Fan 10 | 10426.441 | RPM| ok| na| > na| na| 3996.803 | 3475.480 | na > System Fan 1 | 9992.006 | RPM| ok| na| > na| na| 3996.803 | 3475.480 | na > System Fan 2 | 10900.371 | RPM| ok| na| > na| na| 3996.803 | 3475.480 | na > CPU0 Vcore | 1.107 | Volts | ok| na| > 0.402 | 0.500 | 1.597 | 1.695 | na > CPU1 Vcore | na | Volts | na| na| > 0.402 | 0.500 | 1.597 | 1.695 | na > Standby 5V | 4.969 | Volts | ok| na| > 4.263 | 4.528 | 5.527 | 5.792 | na > System 5V| 4.851 | Volts | ok| na| > 4.263 | 4.528 | 5.527 | 5.792 | na > System 3.3V | 3.234 | Volts | ok| na| > 2.822 | 2.999 | 3.675 | 3.851 | na > 3V CMOS Sense| 3.028 | Volts | ok| na| > 2.617 | 2.781 | na| na| na > CPU0 Therm Diode | na | degrees C | na| na| > 10.000| na| 68.000| 80.000| 95.000 > CPU1 Therm Diode | na | degrees C | na| na| > 10.000| na| 68.000| 80.000| 95.000 > CPU0 ThermDiode2 | na | degrees C | na| na| > 10.000| na| 68.000| 80.000| 95.000 > CPU1 The
Re: [Freeipmi-devel] Trouble w/ HP ProLiant and FreeIPMI (ipmi-sensors)
Hey Al, here is the sdr-cache. 'sdr-cache-p300slg01.10.136.17.128' is the file for gtseval-ipmi, 'sdr-cache-p300slg01.10.136.17.170' is an other cache file from a call of ipmi-sensors which works fine. I'm using FreeIPMI on a system with SUSE 10.1. - p300slg01:/usr/local/src # uname -a Linux p300slg01 2.6.16.27-0.9-smp #1 SMP Tue Feb 13 09:35:18 UTC 2007 i686 i686 i386 GNU/Linux - In your test4-code, I had to change the following lines to compile w/o errors: common/src/pstdout.c -243: fprintf(stderr, "Default stack size = %li bytes \n", mystacksize); +243: fprintf(stderr, "Default stack size = %li bytes \n", (long)mystacksize); +501: va_list vacpy; - I've tested FreeIPMI locally again. I was wrong, it crashes, too. I guess, I was confused with IPMItool, which runs fine locally but gives warnings over the network. Don't know whether it helps you: Locally: [EMAIL PROTECTED]:~/ipmi/usr/bin> ./ipmitool -I open sensor ACPI State | 0x1| discrete | 0x0180| na| na| na| na| na| na System Reset | 0x0| discrete | 0x0080| na| na| na| na| na| na POST Error | na | discrete | na| na| na| na| na| na| na Memory ECC | na | discrete | na| na| na| na| na| na| na PCI Error| na | discrete | na| na| na| na| na| na| na Fan Error| na | discrete | na| na| na| na| na| na| na Watchdog | na | discrete | na| na| na| na| na| na| na CPU Fan 1| 9992.006 | RPM| ok| na| na| na| 3996.803 | 3475.480 | na CPU Fan 2| 10426.441 | RPM| ok| na| na| na| 3996.803 | 3475.480 | na CPU Fan 3| 9992.006 | RPM| ok| na| na| na| 3996.803 | 3475.480 | na CPU Fan 4| 10426.441 | RPM| ok| na| na| na| 3996.803 | 3475.480 | na CPU Fan 5| 9223.391 | RPM| ok| na| na| na| 3996.803 | 3475.480 | na CPU Fan 6| 10900.371 | RPM| ok| na| na| na| 3996.803 | 3475.480 | na CPU Fan 7| 9992.006 | RPM| ok| na| na| na| 3996.803 | 3475.480 | na CPU Fan 8| 10900.371 | RPM| ok| na| na| na| 3996.803 | 3475.480 | na CPU Fan 9| 9992.006 | RPM| ok| na| na| na| 3996.803 | 3475.480 | na CPU Fan 10 | 10426.441 | RPM| ok| na| na| na| 3996.803 | 3475.480 | na System Fan 1 | 9992.006 | RPM| ok| na| na| na| 3996.803 | 3475.480 | na System Fan 2 | 10900.371 | RPM| ok| na| na| na| 3996.803 | 3475.480 | na CPU0 Vcore | 1.107 | Volts | ok| na| 0.402 | 0.500 | 1.597 | 1.695 | na CPU1 Vcore | na | Volts | na| na| 0.402 | 0.500 | 1.597 | 1.695 | na Standby 5V | 4.969 | Volts | ok| na| 4.263 | 4.528 | 5.527 | 5.792 | na System 5V| 4.851 | Volts | ok| na| 4.263 | 4.528 | 5.527 | 5.792 | na System 3.3V | 3.234 | Volts | ok| na| 2.822 | 2.999 | 3.675 | 3.851 | na 3V CMOS Sense| 3.028 | Volts | ok| na| 2.617 | 2.781 | na| na| na CPU0 Therm Diode | na | degrees C | na| na| 10.000| na| 68.000| 80.000| 95.000 CPU1 Therm Diode | na | degrees C | na| na| 10.000| na| 68.000| 80.000| 95.000 CPU0 ThermDiode2 | na | degrees C | na| na| 10.000| na| 68.000| 80.000| 95.000 CPU1 ThermDiode2 | na | degrees C | na| na| 10.000| na| 68.000| 80.000| 95.000 AMB Temp | 29.000 | degrees C | ok| na| 10.000| na| 30.000| 45.000| na MultiBit ECC ER | 0x0| discrete | 0x0180| na| na| na| na| na| na VDD Power Fail | 0x0| discrete | 0x0180| na| na| na| na| na| na Reset| 0x0| discrete | 0x0180| na| na| na| na| na| na Identify | 0x0| discrete | 0x0180| na| na| na| na| na| na NMI | 0x0| discrete | 0x0180| na| na| na
Re: [Freeipmi-devel] Trouble w/ HP ProLiant and FreeIPMI (ipmi-sensors)
Hey Gregor, Thanks. Looks like you did the gdb correctly, I see what I want to see :-) I'll take a look and let you know what I find. Al On Sun, 2007-10-07 at 12:12 +0200, Gregor Dschung wrote: > Hi Al, > > I attach again the output of the call with --debug and the backtrace. It > was the first time that I used gdb, so I hope I understood the tutorials > :) > > At the moment I'm not able to run ipmi-sensors locally, because I'm not > root on "gtseval" (the host of gtseval-ipmi) and I've to wait until I get > rw-rights for /dev/ipmi0 again. And we have week-end ;) > > You are right, I'm running the IPMItool and FreeIPMI on an i386. On > gtseval is a 64bit-System, so perhaps this is the reason for not crashing > locally. > > Have a nice Sunday, > Gregor > > > > Hey Gregor, > > > > Can't see anything suspicuous in the code. Here's another tar.gz that I > > added a whole bunch of extra printfs to try and give me more information, > > could you run again (./configure --enable-debug and run ipmi-sensors with > > --debug again). Also, you mentioned that ipmi-sensors completes locally > > without issue. Are the number of sensor listed below (ending w/ CPU1 Dmn > > 1 Temp) the same as the number of sensors listed when you run locally? > > > > Also, is a core dump being output by this crash? Could you run gdb > > against the core and get a backtrace? That'd be a lot of help too. > > > > Thanks for helping me look into this, > > > > Al > > > >> Hi Al, > >> > >> thanks for your fast answer. > >> > >> I've tested your test-version and it seems to be on the correct way. It > >> still crashes, but now I get sensor-data :) : > >> > >> [...] > >> > > > > > > -- > > Albert Chu > > [EMAIL PROTECTED] > > 925-422-5311 > > Computer Scientist > > High Performance Systems Division > > Lawrence Livermore National Laboratory > > -- Albert Chu [EMAIL PROTECTED] 925-422-5311 Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
Re: [Freeipmi-devel] Trouble w/ HP ProLiant and FreeIPMI (ipmi-sensors)
Hi Al, I attach again the output of the call with --debug and the backtrace. It was the first time that I used gdb, so I hope I understood the tutorials :) At the moment I'm not able to run ipmi-sensors locally, because I'm not root on "gtseval" (the host of gtseval-ipmi) and I've to wait until I get rw-rights for /dev/ipmi0 again. And we have week-end ;) You are right, I'm running the IPMItool and FreeIPMI on an i386. On gtseval is a 64bit-System, so perhaps this is the reason for not crashing locally. Have a nice Sunday, Gregor > Hey Gregor, > > Can't see anything suspicuous in the code. Here's another tar.gz that I > added a whole bunch of extra printfs to try and give me more information, > could you run again (./configure --enable-debug and run ipmi-sensors with > --debug again). Also, you mentioned that ipmi-sensors completes locally > without issue. Are the number of sensor listed below (ending w/ CPU1 Dmn > 1 Temp) the same as the number of sensors listed when you run locally? > > Also, is a core dump being output by this crash? Could you run gdb > against the core and get a backtrace? That'd be a lot of help too. > > Thanks for helping me look into this, > > Al > >> Hi Al, >> >> thanks for your fast answer. >> >> I've tested your test-version and it seems to be on the correct way. It >> still crashes, but now I get sensor-data :) : >> >> [...] >> > > > -- > Albert Chu > [EMAIL PROTECTED] > 925-422-5311 > Computer Scientist > High Performance Systems Division > Lawrence Livermore National Laboratory > gdb-output.tar.bz2 Description: application/bzip ipmi-sensors.debug.tar.bz2 Description: application/bzip ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
Re: [Freeipmi-devel] Trouble w/ HP ProLiant and FreeIPMI (ipmi-sensors)
Hi Al, sorry, I forgot to mention that I've used FreeIPMI 0.4.3. Now, I've compiled the new 0.4.5 with the debug-flag. That's the whole output: - p300slg01:/usr # ipmi-sensors -h gtseval-ipmi -u ADMIN -P --debug Password: RMCP Header: [ 6h] = version[ 8b] [ 0h] = reserved[ 8b] [ FFh] = sequence_number[ 8b] [ 7h] = message_class.class[ 5b] [ 0h] = message_class.reserved[ 2b] [ 0h] = message_class.ack[ 1b] IPMI Session Header: [ 0h] = authentication_type[ 8b] [ 0h] = session_sequence_number[32b] [ 0h] = session_id[32b] IPMI Message Header: [ 20h] = rs_addr[ 8b] [ 0h] = rs_lun[ 2b] [ 6h] = net_fn[ 6b] [ C8h] = checksum1[ 8b] [ 81h] = rq_addr[ 8b] [ 0h] = rq_lun[ 2b] [ 0h] = rq_seq[ 6b] IPMI Command Data: -- [ 38h] = cmd[ 8b] [ Eh] = channel_number[ 4b] [ 0h] = reserved1[ 4b] [ 2h] = maximum_privilege_level[ 4b] [ 0h] = reserved2[ 4b] RMCP Header: [ 6h] = version[ 8b] [ 0h] = reserved[ 8b] [ FFh] = sequence_number[ 8b] [ 7h] = message_class.class[ 5b] [ 0h] = message_class.reserved[ 2b] [ 0h] = message_class.ack[ 1b] IPMI Session Header: [ 0h] = authentication_type[ 8b] [ 0h] = session_sequence_number[32b] [ 0h] = session_id[32b] [ 10h] = ipmi_msg_len[ 8b] IPMI Message Header: [ 81h] = rq_addr[ 8b] [ 0h] = rq_lun[ 2b] [ 7h] = net_fn[ 6b] [ 63h] = checksum1[ 8b] [ 20h] = rs_addr[ 8b] [ 0h] = rs_lun[ 2b] [ 0h] = rq_seq[ 6b] IPMI Command Data: -- [ 38h] = cmd[ 8b] [ 0h] = comp_code[ 8b] [ 2h] = channel_number[ 8b] [ 1h] = authentication_type.none[ 1b] [ 0h] = authentication_type.md2[ 1b] [ 1h] = authentication_type.md5[ 1b] [ 0h] = authentication_type.reserved1[ 1b] [ 1h] = authentication_type.straight_password_key[ 1b] [ 0h] = authentication_type.oem_prop[ 1b] [ 0h] = authentication_type.reserved2[ 2b] [ 0h] = authentication_status.anonymous_login[ 1b] [ 0h] = authentication_status.null_username[ 1b] [ 1h] = authentication_status.non_null_username[ 1b] [ 0h] = authentication_status.user_level_authentication[ 1b] [ 0h] = authentication_status.per_message_authentication[ 1b] [ 0h] = authentication_status.reserved[ 3b] [ 0h] = reserved1[ 8b] [ 0h] = oem_id[24b] [ 0h] = oem_auxiliary_data[ 8b] IPMI Trailer: -- [ 8Dh] = checksum2[ 8b] RMCP Header: [ 6h] = version[ 8b] [ 0h] = reserved[ 8b] [ FFh] = sequence_number[ 8b] [ 7h] = message_class.class[ 5b] [ 0h] = message_class.reserved[ 2b] [ 0h] = message_class.ack[ 1b] IPMI Session Header: [ 0h] = authentication_type[ 8b] [ 0h] = session_sequence_number[32b] [ 0h] = session_id[32b] IPMI Message Header: [ 20h] = rs_addr[ 8b] [ 0h] = rs_lun[ 2b] [ 6h] = net_fn[ 6b] [ C8h] = checksum1[ 8b] [ 81h] = rq_addr[ 8b] [ 0h] = rq_lun[ 2b] [ 0h] = rq_seq[ 6b] IPMI Command Data: -- [ 39h] = cmd[ 8b] [ 2h] = authentication_type[ 4b] [ 0h] = reserved[ 4b] [ BYTE ARRAY ... ] = user_name[16B] [ 41h 44h 4Dh 49h 4Eh 00h 00h 00h ] [ 00h 00h 00h 00h 00h 00h 00h 00h ] RMCP Header: [ 6h] = version[ 8b] [ 0h] = reserved[ 8b] [ FFh] = sequence_number[ 8b] [ 7h] = message_class.class[ 5b] [ 0h] = message_class.reserved[ 2b] [ 0h] = message_class.ack[ 1b] IPMI Session Header: [ 0h] = authentication_type[ 8b] [ 0h] = session_sequence_number[32b] [ 0h] = session_id[32b] [ 1Ch] = ipmi_msg_len[ 8b] IPMI Message Header: [ 81h] = rq_addr[ 8b] [ 0h] = rq_lun[ 2b] [ 7h] = net_fn[ 6b] [ 63h] = checksum1[ 8b] [ 20h] = rs_addr[ 8b] [ 0h] = rs_lun[ 2b] [ 0h] = rq_seq[ 6b] IPMI Command Data: -- [ 39h] = cmd[ 8b] [
Re: [Freeipmi-devel] Trouble w/ HP ProLiant and FreeIPMI (ipmi-sensors)
Hey Greg, Is this with FreeIPMI 0.4.X? I'm not 100% sure of the issue skimming code real quick. Could you try with the debug rpms (ftp://ftp.zresearch.com/pub/freeipmi/0.4.5.debug/) and running with the --debug option? Or if you compiled yourself running ./configure with -- enable-debug? Thanks, Al On Thu, 2007-10-04 at 14:05 +0200, Gregor Dschung wrote: > Hi, > > I'm trying to read sensor-data with ipmi-sensors from an HP ProLiant > DL140G3, but everytime it crashes. > > Even if I read the data with ipmitool, I'll get warnings (I mailed this > issue already on the ipmitool mailing list). > > I'm not good in debugging such issues, so I hope you can help me. > > - > p300slg01:~/.freeipmi/sdr-cache # ipmi-sensors -h gtseval-ipmi -u ADMIN -P > Password: > *** glibc detected *** ipmi-sensors: free(): invalid pointer: 0x0806d680 *** > === Backtrace: = > /lib/libc.so.6[0xb7c2e911] > /lib/libc.so.6(__libc_free+0x84)[0xb7c2ff84] > ipmi-sensors[0x805258a] > ipmi-sensors[0x805269f] > ipmi-sensors[0x804b394] > ipmi-sensors[0x804b4fb] > ipmi-sensors[0x8056b7f] > ipmi-sensors[0x804b606] > /lib/libc.so.6(__libc_start_main+0xdc)[0xb7be087c] > ipmi-sensors[0x804a561] > === Memory map: > 08048000-08062000 r-xp 08:04 40170 /usr/sbin/ipmi-sensors > 08062000-08063000 rw-p 0001a000 08:04 40170 /usr/sbin/ipmi-sensors > 08063000-08085000 rw-p 08063000 00:00 0 [heap] > b7a0-b7a21000 rw-p b7a0 00:00 0 > b7a21000-b7b0 ---p b7a21000 00:00 0 > b7b3a000-b7b44000 r-xp 08:04 16403 /lib/libgcc_s.so.1 > b7b44000-b7b45000 rw-p 9000 08:04 16403 /lib/libgcc_s.so.1 > b7b7a000-b7b7b000 rw-p b7b7a000 00:00 0 > b7b7b000-b7bb r--s 08:04 233346 /var/run/nscd/passwd > b7bb-b7bb2000 rw-p b7bb 00:00 0 > b7bb2000-b7bc3000 r-xp 08:04 16372 /lib/libnsl-2.4.so > b7bc3000-b7bc5000 rw-p 0001 08:04 16372 /lib/libnsl-2.4.so > b7bc5000-b7bc7000 rw-p b7bc5000 00:00 0 > b7bc7000-b7bca000 r-xp 08:04 1619810 > /usr/lib/libgpg-error.so.0.1.3 > b7bca000-b7bcb000 rw-p 2000 08:04 1619810 > /usr/lib/libgpg-error.so.0.1.3 > b7bcb000-b7ce4000 r-xp 08:04 16361 /lib/libc-2.4.so > b7ce4000-b7ce6000 r--p 00118000 08:04 16361 /lib/libc-2.4.so > b7ce6000-b7ce8000 rw-p 0011a000 08:04 16361 /lib/libc-2.4.so > b7ce8000-b7ceb000 rw-p b7ce8000 00:00 0 > b7ceb000-b7d0e000 r-xp 08:04 16369 /lib/libm-2.4.so > b7d0e000-b7d1 rw-p 00022000 08:04 16369 /lib/libm-2.4.so > b7d1-b7d11000 rw-p b7d1 00:00 0 > b7d11000-b7d5f000 r-xp 08:04 260935 > /usr/lib/libgcrypt.so.11.2.1 > b7d5f000-b7d61000 rw-p 0004d000 08:04 260935 > /usr/lib/libgcrypt.so.11.2.1 > b7d61000-b7dd7000 r-xp 08:04 364978 > /usr/lib/libfreeipmi.so.4.0.0 > b7dd7000-b7eb1000 rw-p 00075000 08:04 364978 > /usr/lib/libfreeipmi.so.4.0.0 > b7eb1000-b7eb8000 r-xp 08:04 488969 > /usr/lib/libipmidetect.so.0.0.0 > b7eb8000-b7eb9000 rw-p 7000 08:04 488969 > /usr/lib/libipmidetect.so.0.0.0 > b7eb9000-b7ec9000 r-xp 08:04 16387 /lib/libpthread-2.4.so > b7ec9000-b7ecb000 rw-p f000 08:04 16387 /lib/libpthread-2.4.so > b7ecb000-b7ecd000 rw-p b7ecb000 00:00 0 > b7ecd000-b7f02000 r--s 08:04 233536 /var/run/nscd/dbTnE5h2 > (deleted) > b7f02000-b7f03000 rw-p b7f02000 00:00 0 > b7f03000-b7f1d000 r-xp 08:04 16354 /lib/ld-2.4.so > b7f1d000-b7f1f000 rw-p 00019000 08:04 16354 /lib/ld-2.4.so > bf894000-bf8b7000 rw-p bf894000 00:00 0 [stack] > e000-f000 ---p 00:00 0 [vdso] > Aborted > p300slg01:~/.freeipmi/sdr-cache # > --- > > Even with the parameter -l ADMIN to force the privilege level to admin, > I'll getting the same output. With other servers (Supermicro) the tool > works fine. > > Regards, > Gregor > -- Albert Chu [EMAIL PROTECTED] 925-422-5311 Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
