[bug #65449] Precision of energy measurement thrown away by printing insufficient decimal places.

[Albert Chu]

Update of bug #65449 (group freeipmi):

 Open/Closed:Open => Closed 


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #65449] Precision of energy measurement thrown away by printing insufficient decimal places.

[Albert Chu]

Follow-up Comment #1, bug #65449 (group freeipmi):

thanks, it'll be in the next release of FreeIPMI.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #65202] Any plans to make new release?

[Albert Chu]

Update of bug#65202 (group freeipmi):

 Open/Closed:Open => Closed 

___

Follow-up Comment #2:

working on release right now


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[sr #111010] inb-outb - inline asm in header sys/io.h

[Albert Chu]

Update of sr#111010 (group freeipmi):

 Open/Closed:Open => Closed 

___

Follow-up Comment #1:

thanks, merged into master and 1.6.X stable branch


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #65203] 1.6.11: build fails with gcc 14.x

[Albert Chu]

Follow-up Comment #1, bug#65203 (group freeipmi):

thanks, i'll try to fixup once i can get a hold of a gcc 14.x somehow.  Do you
consider this a requirement to fix before a new release (given your previous
ticket)?


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #65202] Any plans to make new release?

[Albert Chu]

Follow-up Comment #1, bug#65202 (group freeipmi):

Hi, yeah I think I can do a new release.  There were several outstanding
issues I wanted to get verified the fixes worked, but the folks in those
tickets never responded.  I'll try to do one by the end of the week.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[sr #110963] ipmi-sensors does not return fan rpm on Lenovo SR650 v3 but ipmitool does

[Albert Chu]

Follow-up Comment #43, sr#110963 (group freeipmi):

I got a potential candidate for merger in this branch

freeipmi-1-6-0-stable-lenovo_workaround

the workaround I've created is now called "altbridging"


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #64824] Can't collect data with hostname is more 64 chara

[Albert Chu]

Follow-up Comment #2, bug#64824 (group freeipmi):

I got an experimental branch with a fix

freeipmi-1-6-0-stable-maxhostnamelen_increase

git clone https://github.com/chu11/freeipmi-mirror.git
git checkout freeipmi-1-6-0-stable-maxhostnamelen_increase
./autogen.sh
./configure
make
cd ipmi-sensors (or whatever tool you want to test with)
./ipmi-sensors -h REALLYLONGHOSTNAME ...

PLMK if it works for you, thanks!


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #64721] segfault when exceeding 1024 fd - replace select() by poll() in ipmi-openipmi-driver.c

[Albert Chu]

Update of bug#64721 (group freeipmi):

 Open/Closed:Open => Closed 

___

Follow-up Comment #5:

closing, this has been merged for awhile


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[sr #110963] ipmi-sensors does not return fan rpm on Lenovo SR650 v3 but ipmitool does

[Albert Chu]

Follow-up Comment #41, sr #110963 (project freeipmi):

Cool.  If you remove the "printfs" in libfreeipmi/sensor-read/sensor-read.c
you should have something that can work for you temporarily.

I just have to debate how to do it.  I'm a little reluctant to change default
behavior in case it breaks things for current users.  So perhaps another
workaround flag.




___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[sr #110963] ipmi-sensors does not return fan rpm on Lenovo SR650 v3 but ipmitool does

[Albert Chu]

Follow-up Comment #39, sr #110963 (project freeipmi):

i think it worked

> 292 | Fan 1 Front Tach | Fan  | 14924.00   | RPM   | 'OK'

discounting my debug prints, does it work for all sensors?

if so, i need to think of how to fold this in for real


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[sr #110963] ipmi-sensors does not return fan rpm on Lenovo SR650 v3 but ipmitool does

[Albert Chu]

Follow-up Comment #37, sr #110963 (project freeipmi):

I notice in your debug output you always run out of a `Hyperscale/SR650v3`
directory.  Are you installing the debug ipmi-sensors there?

Try running out of the cloned build directory instead.  I'm wondering if your
ipmi-sensors could be picking up the system libfreeipmi by accident (vs using
my hacked libfreeipmi in the build directory).


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[sr #110963] ipmi-sensors does not return fan rpm on Lenovo SR650 v3 but ipmitool does

[Albert Chu]

Follow-up Comment #35, sr #110963 (project freeipmi):

something isn't quite right, even my printf debug statements aren't appearing
in your output.  Are my hacks in the branch you are building?  Here's what I
get when I run git log.

```
>git log | head -n5
commit 1db6ac40eaecaf84d7615a5a2fd6f5b63919b2bc
Author: Albert Chu 
Date:   Sat Dec 2 08:38:48 2023 -0800

hacks
```





___

Reply to this item at:

  <https://savannah.gnu.org/support/?110963>

___
Message sent via Savannah
https://savannah.gnu.org/

[sr #110963] ipmi-sensors does not return fan rpm on Lenovo SR650 v3 but ipmitool does

[Albert Chu]

Follow-up Comment #33, sr #110963 (project freeipmi):

remember to "git fetch" to update the branch (or you can re-clone too).


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[sr #110963] ipmi-sensors does not return fan rpm on Lenovo SR650 v3 but ipmitool does

[Albert Chu]

Follow-up Comment #32, sr #110963 (project freeipmi):

crud, i'm sorry, I think I pushed the wrong code to that branch ... can you
try again.  thanks.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[sr #110963] ipmi-sensors does not return fan rpm on Lenovo SR650 v3 but ipmitool does

[Albert Chu]

Follow-up Comment #30, sr #110963 (project freeipmi):

I think you forgot to run with --workaround-flags=assumebmcowner


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[sr #110963] ipmi-sensors does not return fan rpm on Lenovo SR650 v3 but ipmitool does

[Albert Chu]

Follow-up Comment #28, sr #110963 (project freeipmi):

Could you show the --debug output for the fan sensor?  Maybe I messed
something up.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[sr #110963] ipmi-sensors does not return fan rpm on Lenovo SR650 v3 but ipmitool does

[Albert Chu]

Follow-up Comment #26, sr #110963 (project freeipmi):

Here's a hack on a branch ... just trying to see if this logic would work
(hopefully no typos in these build instructions):

https://github.com/chu11/freeipmi-mirror/tree/lenovo_workaround

git clone https://github.com/chu11/freeipmi-mirror.git

cd freeipmi-mirror
git checkout lenovo_workaround
./autogen.sh
./configure --enable-debug
make
cd ipmi-sensors
./ipmi-sensors --workaround-flags=assumebmcowner




___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[sr #110963] ipmi-sensors does not return fan rpm on Lenovo SR650 v3 but ipmitool does

[Albert Chu]

Follow-up Comment #25, sr #110963 (project freeipmi):

Ok, seems that’s the answer.  Lemme see if I can figure out a workaround.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[sr #110963] ipmi-sensors does not return fan rpm on Lenovo SR650 v3 but ipmitool does

[Albert Chu]

Follow-up Comment #23, sr #110963 (project freeipmi):

so that sorta worked, although 0 rpm doesn't sound right.

looking through more code, i have a theory what might be going on.

on your board i see

```
172.16.40.114: [  10h] = sensor_owner_id[ 7b]
172.16.40.114: [   3h] = sensor_owner_lun[ 2b]
172.16.40.114: [   0h] = sensor_owner_lun.reserved[ 2b]
172.16.40.114: [   0h] = channel_number[ 4b]
```

the sensor owner is the typical one and the lun is != 0.

but in my code I have


```
if (slave_address == IPMI_SLAVE_ADDRESS_BMC && sensor_owner_lun ==
IPMI_BMC_IPMB_LUN_BMC)
   don't do bridging
else
   do bridging

```

which short answer, I do "bridging" when the address & lun aren't the BMC, but
it appears ipmitool may not.  It may only do bridging when the address is not
the BMC.

My assumption is that the bridging I do just happens to work on most
motherboards, but it doesn't on yours (thus the 0xC3 error we saw earlier). 
But it does work the way ipmitool does it.

I'm not sure how to work around this for the moment, but lets see if we can
verify.

ipmi-raw 0 0x04 0x2d 0x81

should emulate what i'm doing now

ipmi-raw 3 0x04 0x2d 0x81

should emulate what ipmitool is doing

my hope is that we'll see

(first case)
rcvd: 2D 00 00 XX XX

(second case)
rcvd: 2D 00 NN XX XX 


where NN will not be 0 in the second case.





___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[sr #110963] ipmi-sensors does not return fan rpm on Lenovo SR650 v3 but ipmitool does

[Albert Chu]

Follow-up Comment #21, sr #110963 (project freeipmi):

Could you try the "assumebmcowner" workaround (without --bridge-sensors). 
AFAICT, ipmitool is not "bridging", even though they should.



___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[sr #110963] ipmi-sensors does not return fan rpm on Lenovo SR650 v3 but ipmitool does

[Albert Chu]

Follow-up Comment #18, sr #110963 (project freeipmi):

Actually I just noticed something in your out of band debug output.

```
>> Sending IPMI command payload
>>netfn   : 0x04
>>command : 0x2d
BUILDING A v2 COMMAND
Local RqAddr 0x20 transit 0:0 target 0x20:0 bridgePossible 1
<< IPMI Response Session Header
<<   Authtype: RMCP+
<<   Payload type: IPMI (0)
<<   Session ID  : 0xa0a2a3a4
<<   Sequence: 0x0309
<<   IPMI Msg/Payload Length : 32
<< IPMI Response Message Header
<<   Rq Addr: 81
<<   NetFn  : 05
<<   Rq LUN : 0
<<   Rs Addr: 20
<<   Rq Seq : 0f
<<   Rs Lun : 0
<<   Command: 2d
<<   Compl Code : 0x00

```

This is the "get sensor reading" command, and it apparently doesn't return an
error (completion code == 0).


Could you do the out of band --debug --bridge-sensors output again?  Your
debug output of that before didn't connect to the server.

i.e. ipmi-sensors -r NUMBER --debug --bridge-sensors -h host -u user -p
password



___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[sr #110963] ipmi-sensors does not return fan rpm on Lenovo SR650 v3 but ipmitool does

[Albert Chu]

Follow-up Comment #17, sr #110963 (project freeipmi):

That said, why your motherboard is returning errors for that sensor is
something you'll probably want to bring up with your vendor.  Could be a
firmware issue or otherwise.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[sr #110963] ipmi-sensors does not return fan rpm on Lenovo SR650 v3 but ipmitool does

[Albert Chu]

Follow-up Comment #16, sr #110963 (project freeipmi):

At this point I'm unconvinced that ipmitool is doing the right thing.  It
appears when the 0xC3 error occurs when reading a sensor, ipmitool will output
data under the assumption the reading was valid.

I've submitted a bug to ipmitool on the mailing list for the time being.  We
can see if anyone responds.




___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[sr #110963] ipmi-sensors does not return fan rpm on Lenovo SR650 v3 but ipmitool does

[Albert Chu]

Follow-up Comment #15, sr #110963 (project freeipmi):

I looked through the ipmitool code and one chunk looks very concerning in
`ipmi_sdr_read_sensor_value()`

```
if (rsp->ccode) { 
 
if ( !((sr.full&& rsp->ccode == 0xcb) ||  
 
   (sr.compact && rsp->ccode == 0xcd)) ) {
 
lprintf(LOG_DEBUG,
 
"Error reading sensor %s (#%02x): %s",
sr.s_id, 
sensor->keys.sensor_num,  
 
val2str(rsp->ccode, completion_code_vals));   
 
} 
 
return
 
}
```

It seems to suggest that if an error occurs during the sensor reading, output
a debug message (if necessary), and then return the sensor reading as though
it were successful.

So this may be a bug in ipmitool in which it gets an error, but ignores the
error.  

What confidence do you have in the RPM values actually being correct?

The RPM may simply be junk data being output.




___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[sr #110963] ipmi-sensors does not return fan rpm on Lenovo SR650 v3 but ipmitool does

[Albert Chu]

Follow-up Comment #14, sr #110963 (project freeipmi):

Unfortunately the ipmitool debug did not have much (they seem to exclude
packet dumps around the area I care about).

Lemme peruse their code and see if there's something obvious they are doing. 
Perhaps it's a workaround of sorts for Lenovo.

Can you tell me the OS and version of ipmitool you're using.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[sr #110963] ipmi-sensors does not return fan rpm on Lenovo SR650 v3 but ipmitool does

[Albert Chu]

Follow-up Comment #12, sr #110963 (project freeipmi):

Hmmm I see

> Sensor reading/event_bitmask retrieval error: sensor reading
> cannot be obtained

The error code is 0xC3 indicating a timeout.

question, you are using the linux ipmi driver, right?  Normally reading from
/dev/ipmi0?  If by chance it's not using it, you can force it with
"ipmi-sensors -D openipmi"

could you get the debug output from ipmitool to show how it's getting the
sensor reading?  Perhaps there will be a clue.

I think `ipmitool sdr -vvv get "Fan 1 Front Tach"` should get it.

(If possible both inband and outofband ... unfortunately, it doesn't appear
ipmitool outputs a lot of debug info with inband).




___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[sr #110963] ipmi-sensors does not return fan rpm on Lenovo SR650 v3 but ipmitool does

[Albert Chu]

Follow-up Comment #10, sr #110963 (project freeipmi):

Your new debugs failed to connect to the server.  Some random mistake I
assume.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[sr #110963] ipmi-sensors does not return fan rpm on Lenovo SR650 v3 but ipmitool does

[Albert Chu]

Follow-up Comment #8, sr #110963 (project freeipmi):


> 260 | PVNN PCH AUX PG | Voltage | N/A| N/A   | Unknown

Are you running against a different motherboard?  I used the id of 260 based
on your original screenshot.

Not sure if we need to start over with the original debug output.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[sr #110963] ipmi-sensors does not return fan rpm on Lenovo SR650 v3 but ipmitool does

[Albert Chu]

Follow-up Comment #6, sr #110963 (project freeipmi):

Could you provide the --debug for --bridge-sensors.  like

ipmi-sensors --record-ids=260 --debug --bridge-sensors

(if possible could you do inband, so the extra out-of-band packet stuff isn't
there)


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[sr #110963] ipmi-sensors does not return fan rpm on Lenovo SR650 v3 but ipmitool does

[Albert Chu]

Follow-up Comment #4, sr #110963 (project freeipmi):

Does --bridge-sensors work?


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[sr #110963] ipmi-sensors does not return fan rpm on Lenovo SR650 v3 but ipmitool does

[Albert Chu]

Follow-up Comment #2, sr #110963 (project freeipmi):

Hi, does the "discretereading" workaround work, i.e.
--workaround-flags=discretereading.  I have noticed this issue before only on
HP motherboards.

If not, could you send me some debug info.  For just one sensor would be
enough, like

ipmi-sensors --debug --record-ids=260

and we can see what's going on.  Perhaps it's a new problem that hasn't been
seen before.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #64792] Bad IPMI DCMI response from Huawei and Xfusion BMCs

[Albert Chu]

Follow-up Comment #4, bug #64792 (project freeipmi):


> But the very new Xfusion FusionOne HPC 1288H V6 servers's datasheet claim to
support DCMI, so there may be hope?  My colleague and I would be happy to
test, if there's some way to get more detailed information from ipmi-dcmi when
it's probing the Xfusion BMC.

It's been a long time since I wrote that tool, I can't think of anything else
that can be done, but I could be forgetting something.

Does any other dcmi software work on this board?  It may be worth pinging the
vendor to verify if it supports DCMI.



___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #64824] Can't collect data with hostname is more 64 chara

[Albert Chu]

Follow-up Comment #1, bug #64824 (project freeipmi):

(sorry for late response, was on leave)

Googling around, I guess the issue has been that gethostname() (on almost all
systems) returns a max of 64 bytes (it's a linux kernel definition), so most
people use MAXHOSTNAMELEN as their "max hostname" buffer size (which I did
here).

But technically, that need not be the case, as when you input a hostname on
the command line, that's not related to gethostname() at all.

I agree on a fix, but it will take a little time to peel MAXHOSTNAMELEN away
and ensure things are portable (b/c MAXHOSTNAMELEN is defined in headers on
most systems).




___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #64792] Bad IPMI DCMI response from Huawei and Xfusion BMCs

[Albert Chu]

Follow-up Comment #2, bug #64792 (project freeipmi):

sorry for late reply as I was on leave.

What kind of workaround are you thinking of?

- A workaround to make DCMI work?  I don't think this is possible, as it
simply appears your board does not support DCMI.

- Are you looking for `ipmi-dcmi` to not return an error if an an error
occurs, so that the slurm logs do not get spammed?  I think such a workaround
would be better served through a wrapper script around `ipmi-dcmi`.




___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[sr #110940] IPMI sensors on Cisco Server 110938

[Albert Chu]

Update of sr #110940 (project freeipmi):

 Open/Closed:Open => Closed 


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #64723] INSTALL file needs additional information about configuration

[Albert Chu]

Update of bug #64723 (project freeipmi):

 Open/Closed:Open => Closed 


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #64724] configure.ac has an old version 1.6.3 hard coded

[Albert Chu]

Update of bug #64724 (project freeipmi):

 Open/Closed:Open => Closed 


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[sr #110938] IPMI sensors on Cisco Server

[Albert Chu]

Update of sr #110938 (project freeipmi):

 Open/Closed:Open => Closed 


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[sr #110940] IPMI sensors on Cisco Server 110938

[Albert Chu]

Follow-up Comment #1, sr #110940 (project freeipmi):

I had to research this as I had forgotten specifics.

Most vendors implement a "Physical Security" via the "physical security
chassis intrusion" specific sensor.  See IPMI specification section 42.2 (just
a few lines down in table).  Thus h is "no intrusion" and != h is one
of the different intrusions listed in that table.

It appears your vendor chose to do differently, implementing asserted vs
deasserted for the sensor.  It has to always be set to asserted or deasserted
(0001h of 0002h).

While not as common, it's not wrong to do that.

I think the developer simply has to recognize that a different type of sensor
for "physical security" exists and handle it.

As an example, the ipmi-sensors --output-sensor-state option handles a wide
variety of "combos" that have been discovered over the years.  It appears
"Physical Security" and "asserted/deasserted" is not yet supported, because
you're the first one to report it :P  I'll add it to my TODO list.




___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[sr #110938] IPMI sensors on Cisco Server

[Albert Chu]

Follow-up Comment #1, sr #110938 (project freeipmi):

Hi,

I don't think there is a mistake.  Different motherboards may implement their
sensors differently than others.

It simply appears that your motherboard ouputs an "event" for open vs closed
(i.e. 0001h vs 0002h).  Whereas the software probably assumes closed means
h (i.e. "no event") and open means != h.

I think the software monitoring this motherboard would simply have to be
tweaked.

Al


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #64723] INSTALL file needs additional information about configuration

[Albert Chu]

Follow-up Comment #4, bug #64723 (project freeipmi):

I've added a little bit to the README on the building an RPM.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #64723] INSTALL file needs additional information about configuration

[Albert Chu]

Follow-up Comment #2, bug #64723 (project freeipmi):

ok, pushed a few notes to the README file, I hope that helps.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #64723] INSTALL file needs additional information about configuration

[Albert Chu]

Follow-up Comment #1, bug #64723 (project freeipmi):

Ugh ... the INSTALL file is unfortunately copied in from autoconf / automake. 
Let me add a little something to the README.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #64724] configure.ac has an old version 1.6.3 hard coded

[Albert Chu]

Follow-up Comment #2, bug #64724 (project freeipmi):

just pushed a change to make master branch's version to 1.7.0 and 

./autogen.sh; ./configure; make; make dist; rpmbuild -ta --with systemd
*.tar.gz 

worked for me


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #64724] configure.ac has an old version 1.6.3 hard coded

[Albert Chu]

Follow-up Comment #1, bug #64724 (project freeipmi):

Hi Ole, ahhh the master branch is usually where development happens that is
not for release candidates, thus the version number is rarely increased until
its release candidate time.  I will increase it to 1.7.0 (or something)
shortly for you.

The release candidate branch is 

freeipmi-1-6-0-stable

which is the branch I would try for your test/experiment instead.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #64721] segfault when exceeding 1024 fd - replace select() by poll() in ipmi-openipmi-driver.c

[Albert Chu]

Follow-up Comment #4, bug #64721 (project freeipmi):

Oops, I didn't finish.

I'll go ahead and apply in master and 1.6.X stable branch.

If we could get original user to verify then could get release out sooner
rather than later (if important).



___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #64721] segfault when exceeding 1024 fd - replace select() by poll() in ipmi-openipmi-driver.c

[Albert Chu]

Follow-up Comment #3, bug #64721 (project freeipmi):

Hi, at a high level glance and very loose testing, this seems to work.  It
seems the original user with the issue hasn't confirmed it works?

https://bugs.schedmd.com/show_bug.cgi?id=17639#c30


I'll go ahead and apply in master and 1.6.X stable branch.




___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #64622] Better function checking in configure.ac

[Albert Chu]

Update of bug #64622 (project freeipmi):

  Status:None => Fixed  
 Open/Closed:Open => Closed 


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #64622] Better function checking in configure.ac

[Albert Chu]

Follow-up Comment #1, bug #64622 (project freeipmi):

thanks, I've applied, it'll be in the next release of FreeIPMI.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #64187] Memory repeated freed

[Albert Chu]

Update of bug #64187 (project freeipmi):

 Open/Closed:Open => Closed 


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #64187] Memory repeated freed

[Albert Chu]

Update of bug #64187 (project freeipmi):

  Status:None => Fixed  


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #64187] Memory repeated freed

[Albert Chu]

Follow-up Comment #3, bug #64187 (project freeipmi):


> Also, do you feel this requires an immediate stable release?

Actually, its been awhile since I've done a release.  If you can confirm this
fix works for you, I will do a release.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #64187] Memory repeated freed

[Albert Chu]

Follow-up Comment #2, bug #64187 (project freeipmi):

A fix has been pushed.

https://git.savannah.gnu.org/cgit/freeipmi.git/commit/?h=freeipmi-1-6-0-stable

Could you please try it out and let me know if it works for you.

Also, do you feel this requires an immediate stable release?


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #64187] Memory repeated freed

[Albert Chu]

Follow-up Comment #1, bug #64187 (project freeipmi):

That is indeed an error, thanks.  Will be fixed shortly.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #63625] ipmi-sensors fails to read many sensor values

[Albert Chu]

Update of bug #63625 (project freeipmi):

 Open/Closed:Open => Closed 


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #63625] ipmi-sensors fails to read many sensor values

[Albert Chu]

Follow-up Comment #3, bug #63625 (project freeipmi):

To be honest, I can't remember why this default was chosen.  But I believe its
because its the more commonly desired one.  On most systems, bridging leads to
an excess (i.e. useless) number of sensors being output.

As systems change and "what is common" changes, could certainly change this. 
But I don't believe its necessary at the moment.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #63625] ipmi-sensors fails to read many sensor values

[Albert Chu]

Follow-up Comment #1, bug #63625 (project freeipmi):

Hi, 

There are several options to try to get output to match up to ipmitool.

1 - --bridge-sensors option
2 - the --shared-sensors option
3 - the "discretereading" workaround

I cannot recall what the defaults are in ipmitool for their output, but they
elect to default differently in some output cases.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #63441] ipmidetectd host aliases

[Albert Chu]

Follow-up Comment #1, bug #63441 (project freeipmi):

Did you really mean for this issue to be with `ipmidetect` and not
`ipmidetectd`?  So that if a user does:

ipmidetect aliasedhost

underneath the covers it knows what host you really mean?  It's a decent idea,
and such support exists in 'whatsup' (which I modeled ipmidetect a bit
after).



___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #61121] After starting freeipmi with systemctl, then exit and report an error

[Albert Chu]

Follow-up Comment #1, bug #61121 (project freeipmi):

hi, would it be possible to run ipmidetectd from the command line with the
--debug option and see if we can get more debugging?  Or to atleast see if
this is specific to systemd or not.  Thanks.

Also, this appears to be the fedora build of FreeIPMI.  Unsure if they have
tweaked / modified the systemd files compared to what is in the upstream of
FreeIPMI.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #57317] sdr/ipmi-sdr-parse-util.c: 2* bad test ?

[Albert Chu]

Update of bug #57317 (project freeipmi):

 Assigned to:None => chu11  
 Open/Closed:Open => Closed 


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[Freeipmi-devel] FreeIPMI 1.6.4 Released

[Albert Chu via Freeipmi-devel]

https://ftp.gnu.org/gnu/freeipmi/freeipmi-1.6.4.tar.gz

o In libfreeipmi, add additional workarounds for packets that are
  re-ordered during sensor bridging.
o In libfreeipmi, add additional sensor / event interpretations.
o In libfreeipmi, fix error return value on bridging requests.
o Add workaround in ipmi-sel for QuantaPlex T42D-2U motherboard,
  whichlists a SDR record that makes no sense.
o Add workaround for Dell Poweredge FC830, which have an error
  when reading the last SDR record on a motherboard.
o Support Supermicro X10 OEM dimm events. 

Al

-- 
Albert Chu
ch...@llnl.gov
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory



___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/freeipmi-devel

Re: [Freeipmi-devel] Inverted IPMI responses

[Albert Chu]

Hey Marc,

I think I see the problem(s).  I've added some tweaks, can you give the
branch "ipmb_network_reorder_race3" from github a shot.

For the ipmi-raw case, you should see a trace message just like last
time that says "reversed obj_cmd responses".  And for the new case,
where there is an error in the first response, you should see the trace
"accept out-of-order with bad completion code".

The ipmi debug packets will still be incorrect though.

Thanks,

Al

On Thu, 2019-01-31 at 15:30 +, GIRARD, MARC wrote:
> Hi Albert,
> 
> I am afraid your fix doesn't solve all cases.
> Maybe it is necessary to reconsider the existence of a race
> condition. I thing the problem is on the BMC side.
> 
> I found two 'unusual' cases : one with ipmi-raw and another one with
> IntelNM and an invalid domain_id.
> See attachments for details
> 
> 
> I apologize for my English: I wish I could be more nuanced and more
> eloquent. I hope you understood me.
> Kind regards / Cordialement
> 
> Marc Girard
> Power Efficiency team
> Atos
-- 
Albert Chu
ch...@llnl.gov
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory



___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/freeipmi-devel

Re: [Freeipmi-devel] Fwd: ipmimonitoring-sensors.c discretereading workaround

[Albert Chu]

Ok, I think the issue was the very first sensor in your motherboard is
an OEM one, leading to the corner case.  I've updated it with a
different fix.  See if that works.

Al

On Thu, 2018-12-13 at 16:53 +0100, Florian wrote:
> Unfortunately the behaviour seems to be same as before.
> Also I found out that this also happens when I just set
> ignore_non_interpretable_sensors to 0, regardless of the
> discrete_reading.
> Here are the debug logs again: https://privatebin.florianstroeger.com
> /?a6ca58fafa858533#UnYEGT64uxq1Pt5p//LVT2jxzga2sKGeUhURExSixkE=
> (Again, more than 6800 lines)
> 
> Florian
> 
> 
> On Wed, Dec 12, 2018 at 10:47 PM Albert Chu  wrote:
> > Ahh, you didn't mention there was an error message :-)
> > 
> > I think this is just a corner case in the example, where it should
> > only
> > be calling a function if the bitmask type is known.  I've updated
> > the
> > example in the same branch.  Could you give it a try?
> > 
> > Al
> > 
> > On Wed, 2018-12-12 at 20:41 +0100, Florian wrote:
> > > Hey,
> > > 
> > > Yes, your recapitulation is correct.
> > > I've also done everything you said in your email again and added
> > the
> > > both debug parameters.
> > > Here is the log: https://privatebin.florianstroeger.com/?fd665f9c
> > dea8
> > > a9c8#F8H5p5lmKmTqiUkMhfwSZgeKLjcyPfrMaXmCj6b0TTQ=
> > > (more than 6800 lines of output)
> > > 
> > > Florian
> > > 
> > > On Wed, Dec 12, 2018 at 8:12 PM Albert Chu 
> > wrote:
> > > > On Wed, 2018-12-12 at 12:27 +0100, Florian wrote:
> > > > > Sorry, I forgot.
> > > > > 
> > > > > I finally get the readings: 
> > > > > root@preisschild-server-2:~/ipmi# gcc -O2 -o ipmimonitoring-
> > > > sensors
> > > > > ipmimonitoring-sensors.c -lipmimonitoring &&
> > ./ipmimonitoring-
> > > > sensors
> > > > > Record ID, Sensor Name, Sensor Number, Sensor Type, Sensor
> > State,
> > > > > Sensor Reading, Sensor Units, Sensor Event/Reading Type Code,
> > > > Sensor
> > > > > Event Bitmask, Sensor Event String
> > > > > 5, Power Meter, 5, Current, N/A, 174.00, W, 9h, 2h, 'Device
> > > > Enabled'
> > > > 
> > > > Ok, good, that means it's working.
> > > > 
> > > > > The only thing now is, I only get it when I set record_ids[]
> > to
> > > > {5,
> > > > > 0}  and record_ids_length = 1.
> > > > > If I set them to the default values (0 and 0), nothing shows,
> > > > unless
> > > > > I set ignore_non_interpretable_sensors to 1.
> > > > 
> > > > Wait a second, so lets go back to the default example file that
> > > > comes
> > > > with FreeIPMI.
> > > > 
> > > > This default example file shows most sensors, but not #5.  And
> > #8 &
> > > > #9
> > > > don't have watt readings.  Correct?
> > > > 
> > > > If you set discrete_reading = 1, watt readings show up on #8 &
> > #9,
> > > > but
> > > > sensor #5 still doesn't show up?  That's what I would expect.
> > > > 
> > > > If you then set ignore_non_interpretable_sensors = 0, then I
> > would
> > > > expect record #5's sensor to show up w/ watt readings.  But
> > you're
> > > > saying at this point no sensors are output at all?
> > > > 
> > > > Al
> > > > 
> > > > > Florian
> > > > > 
> > > > > On Wed, Dec 12, 2018 at 12:50 AM Albert Chu 
> > > > wrote:
> > > > > > Just to double check, ignore_non_interpretable_sensors is
> > set
> > > > to 0?
> > > > > > 
> > > > > > Al
> > > > > > 
> > > > > > On Tue, 2018-12-11 at 20:55 +0100, Florian wrote:
> > > > > > > Hi,
> > > > > > > 
> > > > > > > Sure, here's the log: https://privatebin.florianstroeger.
> > com/
> > > > ?77d
> > > > > > 4fd1
> > > > > > > 8f282d55e#K0MG3NEiH0+sZvFNo+s8F9zvm1DYTj3f6kU8OEjvtmQ=
> > > > > > > 
> > > > > > > Florian
> > > > > > > 
> > > > > > > On Tue, Dec 11, 2018 at 7:29 PM Albert Chu  > v>
> > > > > > wrote:
> > > > > >

Re: [Freeipmi-devel] Fwd: ipmimonitoring-sensors.c discretereading workaround

[Albert Chu]

Ahh, you didn't mention there was an error message :-)

I think this is just a corner case in the example, where it should only
be calling a function if the bitmask type is known.  I've updated the
example in the same branch.  Could you give it a try?

Al

On Wed, 2018-12-12 at 20:41 +0100, Florian wrote:
> Hey,
> 
> Yes, your recapitulation is correct.
> I've also done everything you said in your email again and added the
> both debug parameters.
> Here is the log: https://privatebin.florianstroeger.com/?fd665f9cdea8
> a9c8#F8H5p5lmKmTqiUkMhfwSZgeKLjcyPfrMaXmCj6b0TTQ=
> (more than 6800 lines of output)
> 
> Florian
> 
> On Wed, Dec 12, 2018 at 8:12 PM Albert Chu  wrote:
> > On Wed, 2018-12-12 at 12:27 +0100, Florian wrote:
> > > Sorry, I forgot.
> > > 
> > > I finally get the readings: 
> > > root@preisschild-server-2:~/ipmi# gcc -O2 -o ipmimonitoring-
> > sensors
> > > ipmimonitoring-sensors.c -lipmimonitoring && ./ipmimonitoring-
> > sensors
> > > Record ID, Sensor Name, Sensor Number, Sensor Type, Sensor State,
> > > Sensor Reading, Sensor Units, Sensor Event/Reading Type Code,
> > Sensor
> > > Event Bitmask, Sensor Event String
> > > 5, Power Meter, 5, Current, N/A, 174.00, W, 9h, 2h, 'Device
> > Enabled'
> > 
> > Ok, good, that means it's working.
> > 
> > > The only thing now is, I only get it when I set record_ids[] to
> > {5,
> > > 0}  and record_ids_length = 1.
> > > If I set them to the default values (0 and 0), nothing shows,
> > unless
> > > I set ignore_non_interpretable_sensors to 1.
> > 
> > Wait a second, so lets go back to the default example file that
> > comes
> > with FreeIPMI.
> > 
> > This default example file shows most sensors, but not #5.  And #8 &
> > #9
> > don't have watt readings.  Correct?
> > 
> > If you set discrete_reading = 1, watt readings show up on #8 & #9,
> > but
> > sensor #5 still doesn't show up?  That's what I would expect.
> > 
> > If you then set ignore_non_interpretable_sensors = 0, then I would
> > expect record #5's sensor to show up w/ watt readings.  But you're
> > saying at this point no sensors are output at all?
> > 
> > Al
> > 
> > > Florian
> > > 
> > > On Wed, Dec 12, 2018 at 12:50 AM Albert Chu 
> > wrote:
> > > > Just to double check, ignore_non_interpretable_sensors is set
> > to 0?
> > > > 
> > > > Al
> > > > 
> > > > On Tue, 2018-12-11 at 20:55 +0100, Florian wrote:
> > > > > Hi,
> > > > > 
> > > > > Sure, here's the log: https://privatebin.florianstroeger.com/
> > ?77d
> > > > 4fd1
> > > > > 8f282d55e#K0MG3NEiH0+sZvFNo+s8F9zvm1DYTj3f6kU8OEjvtmQ=
> > > > > 
> > > > > Florian
> > > > > 
> > > > > On Tue, Dec 11, 2018 at 7:29 PM Albert Chu 
> > > > wrote:
> > > > > > Hey Florian,
> > > > > > 
> > > > > > Good, so atleast the "discrete reading" workaround works
> > > > correctly
> > > > > > now.
> > > > > > 
> > > > > > > With IPM_MONITORING_FLAGS_DEBUG I did not get any more
> > logs,
> > > > so I
> > > > > > did
> > > > > > > it with IPMI_MONITORING_FLAGS_DEBUG_IPMI_PACKETS.
> > > > > > 
> > > > > > Could you set both of these with the or operator and re-
> > run,
> > > > i.e 
> > > > > > 
> > > > > > unsigned int ipmimonitoring_init_flags =
> > > > IPM_MONITORING_FLAGS_DEBUG
> > > > > > |
> > > > > > IPMI_MONITORING_FLAGS_DEBUG_IPMI_PACKETS
> > > > > > 
> > > > > > Thanks,
> > > > > > Al
> > > > > > 
> > > > > > 
> > > > > > On Tue, 2018-12-11 at 08:52 +0100, Florian wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > -- Forwarded message -
> > > > > > > From: Florian 
> > > > > > > Date: Tue, Dec 11, 2018 at 8:52 AM
> > > > > > > Subject: Re: [Freeipmi-devel] ipmimonitoring-sensors.c
> > > > > > > discretereading workaround
> > > > > > > To: Albert Chu 
> > > > > > > 
> > > > > > > 
> > > > > &

Re: [Freeipmi-devel] Fwd: ipmimonitoring-sensors.c discretereading workaround

[Albert Chu]

Just to double check, ignore_non_interpretable_sensors is set to 0?

Al

On Tue, 2018-12-11 at 20:55 +0100, Florian wrote:
> Hi,
> 
> Sure, here's the log: https://privatebin.florianstroeger.com/?77d4fd1
> 8f282d55e#K0MG3NEiH0+sZvFNo+s8F9zvm1DYTj3f6kU8OEjvtmQ=
> 
> Florian
> 
> On Tue, Dec 11, 2018 at 7:29 PM Albert Chu  wrote:
> > Hey Florian,
> > 
> > Good, so atleast the "discrete reading" workaround works correctly
> > now.
> > 
> > > With IPM_MONITORING_FLAGS_DEBUG I did not get any more logs, so I
> > did
> > > it with IPMI_MONITORING_FLAGS_DEBUG_IPMI_PACKETS.
> > 
> > Could you set both of these with the or operator and re-run, i.e 
> > 
> > unsigned int ipmimonitoring_init_flags = IPM_MONITORING_FLAGS_DEBUG
> > |
> > IPMI_MONITORING_FLAGS_DEBUG_IPMI_PACKETS
> > 
> > Thanks,
> > Al
> > 
> > 
> > On Tue, 2018-12-11 at 08:52 +0100, Florian wrote:
> > > 
> > > 
> > > -- Forwarded message -
> > > From: Florian 
> > > Date: Tue, Dec 11, 2018 at 8:52 AM
> > > Subject: Re: [Freeipmi-devel] ipmimonitoring-sensors.c
> > > discretereading workaround
> > > To: Albert Chu 
> > > 
> > > 
> > > Hey Al,
> > > 
> > > Thanks for the fast patch,
> > > 
> > > We got at least a partial victory:
> > > After setting discrete_reading to 1, I got two of the PSU sensors
> > > working: 
> > > 8, Power Supply 1, 8, Power Supply, Nominal, 45.00, W, 6Fh, 1h,
> > > 'Presence detected'
> > > 9, Power Supply 2, 9, Power Supply, Nominal, 40.00, W, 6Fh, 1h,
> > > 'Presence detected'
> > > Unfortunately sensor 5 (total power meter)  doesn't show up. 
> > > 
> > > After setting record_ids[] to {5, 0}  and record_ids_length = 1,
> > I
> > > only get the headers:
> > > Record ID, Sensor Name, Sensor Number, Sensor Type, Sensor State,
> > > Sensor Reading, Sensor Units, Sensor Event/Reading Type Code,
> > Sensor
> > > Event Bitmask, Sensor Event String
> > > 
> > > Before your patch it looked like this:
> > > Record ID, Sensor Name, Sensor Number, Sensor Type, Sensor State,
> > > Sensor Reading, Sensor Units, Sensor Event/Reading Type Code,
> > Sensor
> > > Event Bitmask, Sensor Event String
> > > 5, Power Meter, 5, Current, N/A, N/A, N/A, 9h, 2h, 'Device
> > Enabled'.
> > > 
> > > With IPM_MONITORING_FLAGS_DEBUG I did not get any more logs, so I
> > did
> > > it with IPMI_MONITORING_FLAGS_DEBUG_IPMI_PACKETS.
> > > I've pasted the logs for that to my privatebin again: https://pri
> > vate
> > >
> > bin.florianstroeger.com/?29b500374675145d#dqIOvHjjtK0FbooesKFeC5Ow2
> > fl
> > > dIWSyuWIRiNnzW+0= 
> > > 
> > > Florian
> > > 
> > > On Tue, Dec 11, 2018 at 1:13 AM Al Chu  wrote:
> > > > Hey Florian,
> > > > 
> > > > I have an experimental branch called ipmimonitoring-discrete-
> > > > reading on
> > > > github here:
> > > > 
> > > > https://github.com/chu11/freeipmi-mirror/tree/ipmimonitoring-di
> > scre
> > > > te-r
> > > > eading
> > > > 
> > > > ./autogen.sh
> > > > ./configure
> > > > make
> > > > make install
> > > > re-compile ipmimonitoring-sensors.c and try it out
> > > > 
> > > > LMK if you need help, like getting to the right branch.  If you
> > > > can't
> > > > make install, LMK and I can show you some linker tricks.
> > > > 
> > > > Al
> > > > 
> > > > On Wed, 2018-12-05 at 20:34 +0100, Florian wrote:
> > > > > Hey Al,
> > > > > 
> > > > > That's awesome!
> > > > > 
> > > > > Sure, I'm totally OK with a git repo. As long as I just need
> > to
> > > > do
> > > > > configure and make I can do it.
> > > > > 
> > > > > Thanks for looking into this so fast!
> > > > > 
> > > > > Florian 
> > > > > 
> > > > > On Wed, Dec 5, 2018 at 8:26 PM Albert Chu 
> > wrote:
> > > > > > Hey Florian,
> > > > > > 
> > > > > > Ok, I think I found a bug.  The "discrete reading" flag is
> > > > passed
> > > > > > to an
> > > > > > und

Re: [Freeipmi-devel] [PATCH v2 0/5]

[Albert Chu]

Everything looks good and works on my one node.  Will push to master
and backport to 1.6.X stable branch shortly.

Is it urgent to do a release?

Al

On Wed, 2018-08-01 at 11:01 -0600, dann frazier wrote:
> I ran into an ARM server that describes its system interface only via
> the SPMI ACPI table and not via SMBIOS. freeipmi has SPMI support,
> but
> its implementation accesses ACPI tables using /dev/mem, which isn't
> safe to do on ARM. In fact, this code is #ifdef'd out for ARM
> platforms.
> 
> This series teaches freeipmi how to parse ACPI tables out of sysfs,
> keeping the fallback /dev/mem implementation as a fallback. It also
> fixes a couple of apparent bugs in the SPMI parsing itself.
> 
> Tested on a HiSilicon D06 ARM Server, and 4 x86 servers:
> HP ProLiant DL165 G7
> HP ProLiant DL385 G7
> QuantaGrid D52B
> Supermicro Super Server
> 
> I've actually not been able to get the existing /dev/mem code to work
> on any platform I've tried myself, so I was unable to regression test
> it.
> 
> v2:
>   * Rebased on current master.
>   * Update Changelog.
>   * Support systems with multiple SPMI instances.
> 
> dann frazier (5):
>   Don't try to separate the header from the ACPI table data
>   Split RSDT/XSDT parsing into new function
>   Add support for parsing SPMI tables exposed via sysfs
>   Allow sysfs SPMI parsing on ARM platforms
>   Correct order of bytes in specification_revision field of ACPI SPMI
> table
> 
>  ChangeLog  |  15 ++
>  libfreeipmi/locate/ipmi-locate-acpi-spmi.c | 259 ---
> --
>  2 files changed, 218 insertions(+), 56 deletions(-)
> 
-- 
Albert Chu
ch...@llnl.gov
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory


___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/freeipmi-devel

Re: [Freeipmi-devel] [RFC][PATCH 0/1] Fix apparent bug w/ ACPI SPMI table parsing

[Albert Chu]

Hey Dann,

As I thought about it, I'm not sure how much the ACPI code has even
been tested (atleast by me).  Almost every motherboard I can recall had
info in DMI/SMBIOS.

Digging into the code history, outside of cleanups & refactoring (which
of course could have introduced issues, but I doubt those issues would
have been at the level of what you found), this code was developed
circa 2004-2005, with the last "real" change in 2006.

So I'm willing to accept your change as is b/c A) it makes sense, B)
you seem to have a system you can half-test against and C) I assume
this code worked long ago on whatever system it was originally
developed against, but who knows if that system even did it correctly.

That said, you seem to be suggesting there are going to be some further
patches down the line for acpi via sysfs.  If that code is coming down
the pipeline, and this code is for it, I can wait for the entire patch
series to come in and it can be added all at once.

Al

On Mon, 2018-07-30 at 15:30 -0600, dann frazier wrote:
> hey.
>   I'm working on a patch to add support to ipmi-locate code to parse
> ACPI
> SPMI tables via sysfs. This is to make ipmi-locate work on an ARM
> system
> we have that describes its BMC only in ACPI (not DMI). Being ARM,
> trolling
> /dev/mem isn't safe, (freeipmi ifdef's that out), so using the
> kernel-exposed
> tables, when available, is a better option.
> 
> While doing this I ran across what seems like a bug, which the
> following patch
> should fix. I say "seems" and "should" because I don't have a system
> where the
> existing /dev/mem snooping code works - with, or without this bug fix
> -
> therefore, I cannot emperically demonstrate the bug. On the systems
> I've
> tested, which do include an SPMI table, ipmi-locate is unable to find
> a valid
> RSDT signature using the /dev/mem method. I'm not sure what I'm doing
> wrong
> there - I tried diabling CONFIG_STRICT_DEVMEM andsetting the
> vm.mmap_min_addr
> sysctl to 0 w/o luck.
> 
> dann frazier (1):
>   Don't try to separate the header from the ACPI table data
> 
>  libfreeipmi/locate/ipmi-locate-acpi-spmi.c | 33 +++-
> --
>  1 file changed, 4 insertions(+), 29 deletions(-)
> 
-- 
Albert Chu
ch...@llnl.gov
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory


___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/freeipmi-devel

[Freeipmi-devel] [bug #53810] Lan channels number

[Albert Chu]

Follow-up Comment #2, bug #53810 (project freeipmi):

ends up also need to update

ipmi-channel-spec.h

I'll go ahead and make the change.

This will be in the next release of FreeIPMI 1.6.2, which I will try to
release semi-soon.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/


___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/freeipmi-devel

[Freeipmi-devel] [bug #49037] lacks ipv6 support

[Albert Chu]

Update of bug #49037 (project freeipmi):

 Open/Closed:Open => Closed 


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/


___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/freeipmi-devel

[Freeipmi-devel] [bug #53193] ipmi-config compatibility scripts mangle parameters through shell

[Albert Chu]

Update of bug #53193 (project freeipmi):

 Open/Closed:Open => Closed 


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/


___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/freeipmi-devel

[Freeipmi-devel] [bug #53810] Lan channels number

[Albert Chu]

Update of bug #53810 (project freeipmi):

Severity:  3 - Normal => 4 - Important  

___

Follow-up Comment #1:

You're right, looks like I missed that errata change.

I can apply your patch as is.  PLMK who to give credit to.  Or if you wish,
you could alternately supply a pull request at:

https://github.com/chu11/freeipmi-mirror

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/


___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/freeipmi-devel

Re: [Freeipmi-devel] Free IPMI Capabilities?

[Albert Chu]

> May I ask if your tool suit, Free IPMI, has the capability of modifying a BMC 
> Firmware Binary File, prior to flashing on a chip such that the the final 
> firmware modifications will have the end user's MAC Address information 
> embedded thereby avoiding the above nightmare scenario?

No.  We leave firmware flashing to the motherboard manufacturer.
FreeIPMI is predominantly for end users.

> If this is not possible, do you know of any open source software to 
> accomplish this?

I'm not aware of anything.

Al


On Sat, Mar 10, 2018 at 9:00 AM, Mark Bennette  wrote:
> Dear Sir or Madam;
>
> I work at the TSD of a Server Motherboard Manufacturer/Reseller.  We often
> run into issues where end customers, corrupt, or alter, the BMC CHIP
> Firmware, e.g. forgotten password, MAC Address issues, such that they end up
> requesting that we send them another BMC chip, with their board's MAC
> Addresses, pre-configured in the CHIP.  This is a laborious task, first
> having to download the firmware, flashing the chip, via EPROM device, then
> installing the chip in a compatible machine, then resetting the info in the
> chip to factory defaults and finally confirming via router DHCP Table the
> validity of the process, e.g. MAC Addresses displayed.
>
> May I ask if your tool suit, Free IPMI, has the capability of modifying a
> BMC Firmware Binary File, prior to flashing on a chip such that the the
> final firmware modifications will have the end user's MAC Address
> information embedded thereby avoiding the above nightmare scenario?
>
> If this is not possible, do you know of any open source software to
> accomplish this?
>
> --
>
> Thanks,
>
> Mark Bennette
>
>
> ___
> Freeipmi-devel mailing list
> Freeipmi-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/freeipmi-devel
>

___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/freeipmi-devel

Re: [Freeipmi-devel] exit code 11

[Albert Chu]

Hi Saba,

This software is not a part of FreeIPMI.  You'll have to contact the
vendor that supplied it.

Al

On Sat, Feb 24, 2018 at 7:38 AM, Saba Ahmadian  wrote:
> Hi there,
>
> I receive error and exit code "11" when running the following command (not
> always but sometimes!)
>
> ipmicfg-linux.x86 -sdr
>
>
> Motherboard:
> Manufacturer: Supermicro
> Product Name: X10DRL-i
> Version: 1.01
>
>
> Would you please help me finding the source of the problem and resolving it?
>
>
> Thanks,
> Saba
>
>
>
>
>
>
> ___
> Freeipmi-devel mailing list
> Freeipmi-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/freeipmi-devel
>

___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/freeipmi-devel

[Freeipmi-devel] [bug #53193] ipmi-config compatibility scripts mangle parameters through shell

[Albert Chu]

Follow-up Comment #1, bug #53193 (project freeipmi):

You're right, that seems much simpler.

Would you like to submit a patch?  Or just let me know the name/email you want
me to give credit to.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/freeipmi-devel

Re: [Freeipmi-devel] Bug when querying bridged sensors

[Albert Chu]

Hi Marc,

Thanks for the patch.  As far as I can tell, you are absolutely right. 
I'm not sure how this code even worked before, although I suspect many
IPMI implementations just automatically sent bridge requests to the
right place reqardless of the LUN.

I have this queued up for a fix in 1.6.2.  I see your patch was against
FreeIPMI 1.5.7.  Do you have a need for me to release a 1.5.8 at some
point in the future?

Al

On Fri, 2018-02-16 at 11:58 +, GIRARD, MARC wrote:
> Hi FreeIPMI Team,
>  
> We experiment a bug when querying bridged sensors of a Bull GPU
> Blade.
>  
> This bug can be solved with the following patch :
>  
> diff -pur freeipmi-1.5.7.orig/libfreeipmi/api/ipmi-lan-session-
> common.c freeipmi-1.5.7/libfreeipmi/api/ipmi-lan-session-common.c
> --- freeipmi-1.5.7.orig/libfreeipmi/api/ipmi-lan-session-
> common.c   2017-08-16 20:28:20.0 +0200
> +++ freeipmi-1.5.7/libfreeipmi/api/ipmi-lan-session-common.c    2018-
> 02-16 12:34:54.369033904 +0100
> @@ -1222,7 +1222,7 @@ _ipmi_cmd_send_ipmb (ipmi_ctx_t ctx, fii
>   ctx->target.net_fn,
>   ctx->target.lun,
>       IPMI_SLAVE_ADDRESS_BMC,
> - IPMI_BMC_IPMB_LUN_SMS_MSG_LUN,
> + IPMI_BMC_IPMB_LUN_BMC ,
>   ctx->io.outofband.rq_seq,
>   obj_ipmb_msg_hdr_rq) < 0)
>  {
>  
> (and probably with identical patch in kcs and ssif interface)
>  
> According to the chapter 7.4 of IPMI specifications, it seems that
> IPMI_BMC_IPMB_LUN_SMS_MSG_LUN (0x02) are used by devices sending
> request to system management software, so I suspect a bug concerning
> all platforms.
>  
> Thank you for your comments.
>  
> (I apologize for my English)
>  
> Regards
> 
> Marc Girard
> Power Efficiency Team
> marc.gir...@atos.net
> https://eu.yourcircuit.com/#/email/marc.gir...@atos.net
> Bull, An Atos company (www.bull.com)
> _______
> Freeipmi-devel mailing list
> Freeipmi-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/freeipmi-devel
-- 
Albert Chu
ch...@llnl.gov
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory


___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/freeipmi-devel

[Freeipmi-devel] FreeIPMI 1.6.1 Released

[Albert Chu]

https://ftp.gnu.org/gnu/freeipmi/freeipmi-1.6.1.tar.gz

FreeIPMI 1.6.1 - 02/02/18
-
o Add IPv6 hostname support to FreeIPMI, all of FreeIPMI can now take
  IPv6 addresses as inputs to "host" parameters, options, or inputs.
o Support significant portions of IPMI IPv6 configuration in
  libfreeipmi.
o Add --no-session option in ipmi-raw.
o Add SDR cache options to ipmi-config.
o Legacy -f short option for --flush-cache and -Q short option for
  quiet-cache.  Backwards compatible for tools that supported it
  before.
o In ipmi-oem, support Gigabyte get-bmc-services and set-bmc-services.
o Various performance improvements:
  - Remove excessive calls to secure_memset to clear memory.
  - Remove excessive memsets and clears of data.
  - Remove unnecessary "double input checks".
  - Remove expensive input checks in libfreeipmi fiid library.
Fallout from this may include FIID_ERR_FIELD_NOT_FOUND errors in
different fiid functions.
  - Remove unnecessary input checks in libfreeipmi fiid library.
  - Add recent 'lookups' of fields in fiid library to internal cache.
o Various minor fixes/improvements
  - Update libfreeipmi core API to use poll() instead of select(), to
avoid issues with applications with a high number of threads.



As a side point, while IPv6 networking support has been added, IPv6
configuration in ipmi-config & bmc-config is not supported in this
release.

Work to support IPv6 configuration in ipmi-config was completed.  However I
lost contact with Ubuntu developers I was collaborating with on this work
(they do not appear to work there anymore).

I lack the hardware to test IPv6 IPMI support, so I elected to leave
this code out of FreeIPMI 1.6.1 b/c it remains untested.

It can be added back in once it is tested.

Al

-- 
Albert Chu
ch...@llnl.gov
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory


___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/freeipmi-devel

Re: [Freeipmi-devel] ipmipower --wait-until command line argument parsing fix

[Albert Chu]

Doh!  Thanks for the catch.  Most users use both at the same time,
which is probably why this was not caught for the longest time.  

Thanks.

Al

On Wed, 2017-11-08 at 21:13 +, Michel Ferland wrote:
> Hello,
> 
> The --wait-until-on and --wait-until-off command line arguments to
> ipmipower are not working, as their respective keys are inverted in
> the command line parsing function. Fixed by patch below.
> 
> Thank you,
> 
> 
> Michel Ferland
> Concepteur logiciel
> Software Designer
> Kontron - An S Company
> ---
> 
> diff -pur freeipmi-1.5.7.orig/ipmipower/ipmipower_argp.c freeipmi-
> 1.5.7/ipmipower/ipmipower_argp.c
> --- freeipmi-1.5.7.orig/ipmipower/ipmipower_argp.c2017-11-07
> 09:16:50.523751999 -0500
> +++ freeipmi-1.5.7/ipmipower/ipmipower_argp.c 2017-11-07
> 09:20:12.915751999 -0500
> @@ -215,10 +215,10 @@ cmdline_parse (int key,
>  case ON_IF_OFF_KEY:   /* --on-if-off */
>    cmd_args->on_if_off++;
>    break;
> -case WAIT_UNTIL_OFF_KEY:   /* --wait-until-on */
> +case WAIT_UNTIL_ON_KEY:   /* --wait-until-on */
>    cmd_args->wait_until_on++;
>    break;
> -case WAIT_UNTIL_ON_KEY:   /* --wait-until-off */
> +case WAIT_UNTIL_OFF_KEY:   /* --wait-until-off */
>    cmd_args->wait_until_off++;
>    break;
>  case OEM_POWER_TYPE_KEY:
> 
> 
> ___
> Freeipmi-devel mailing list
> Freeipmi-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/freeipmi-devel
-- 
Albert Chu
ch...@llnl.gov
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory


___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/freeipmi-devel

[Freeipmi-devel] [bug #52290] freeipmi: configure misdetetcs features using the build architecture cpp

[Albert Chu]

Update of bug #52290 (project freeipmi):

 Open/Closed:Open => Closed 


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/freeipmi-devel

[Freeipmi-devel] [bug #52290] freeipmi: configure misdetetcs features using the build architecture cpp

[Albert Chu]

Follow-up Comment #2, bug #52290 (project freeipmi):

added to master & freeipmi 1.5.X stable branch

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/freeipmi-devel

[Freeipmi-devel] [bug #52290] freeipmi: configure misdetetcs features using the build architecture cpp

[Albert Chu]

Follow-up Comment #1, bug #52290 (project freeipmi):

at a high level, looks fine to me.  Will play with the patch later this week.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/freeipmi-devel

[Freeipmi-devel] [patch #9457] Use ChangeLog date instead of build date

[Albert Chu]

Update of patch #9457 (project freeipmi):

 Open/Closed:Open => Closed 


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/freeipmi-devel

[Freeipmi-devel] [patch #9457] Use ChangeLog date instead of build date

[Albert Chu]

Follow-up Comment #1, patch #9457 (project freeipmi):

seems like a good idea to me

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/freeipmi-devel

[Freeipmi-devel] FreeIPMI 1.5.7 Released

[Albert Chu]

http://ftp.gnu.org/gnu/freeipmi/freeipmi-1.5.7.tar.gz

FreeIPMI 1.5.7 - 08/16/17
-
o In libipmimonitoring, fix several mem-leak corner cases.

Al

-- 
Albert Chu
ch...@llnl.gov
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory



___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/freeipmi-devel

[Freeipmi-devel] FreeIPMI 1.6.0-alpha1 - testing help requested

[Albert Chu]

Just released the alpha release for FreeIPMI 1.6.0.

http://alpha.gnu.org/gnu/freeipmi/freeipmi-1.6.0.alpha1.tar.gz

High level description of changes can be found here: 

http://git.savannah.gnu.org/cgit/freeipmi.git/tree/NEWS

Requesting some testing help, as the new IPMI IPv6 configuration via
ipmi-config is **completely untested**, as I do not possess a machine
with the feature.  Worked with other folks to add the "checkout" portion
of the code, so that should work (assuming I didn't break it), but the
"commit" portion of the code I added has never been tested.

I'd appreciate if anyone with a machine that knows they have IPMI IPv6
support could try and test it and iterate fixes as needed.  

Al

-- 
Albert Chu
ch...@llnl.gov
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory



___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/freeipmi-devel

Re: [Freeipmi-devel] ipmi_monitoring_sensor_readings_by_record_id: internal error

[Albert Chu]

Awesome.  If you could, perhaps update the stackoverflow with the
solution.

Al

On Tue, 2017-07-18 at 17:16 -0700, Sohan Chowdary Kollu wrote:
> I have set the driver to -1 to use default . It worked like a charm.
> Thanks a lot.
> 
> On Tue, Jul 18, 2017 at 12:15 PM, Albert Chu <ch...@llnl.gov> wrote:
> There's clearly some communication problems with the
> motherboard,
> leading to the "internal IPMI errors".  Many times we send a
> request and
> don't even see a response.  In atleast one case before, the
> response
> wasn't even a fully formed packet.
> 
> But this made me realize what is the possible problem.
> 
> When you run IPMI commands (i.e. ipmi-sensors), are you using
> one of the
> kernel device drivers (e.g. linux defaults to /dev/ipmi0) as
> your
> communication driver?
> 
> The default ipmimonitoring-sensors example happens to use the
> KCS
> driver, which is separate and not related to the kernel one.
> It may be
> conflicting w/ the kernel device driver.  Effectively they are
> both
> doing communication to the BMC but not sharing a lock.
> 
> If you are using  /dev/ipmi0, if you changed the
> ipmimonitoring example
> to use the IPMI_MONITORING_DRIVER_TYPE_OPENIPMI driver,
> thing'll
> probably work out.
> 
> Al
> 
> On Tue, 2017-07-18 at 11:43 -0700, Sohan Chowdary Kollu wrote:
> > I am using 1.5.5 version.
> >
> > Below are the packet details along with errors. Except for
> the 3rd
> > scenario all other errors are very frequent
> >
> >
> > 1)
> >
> > Failed right away (first sdr request in the trace)
> >
> >
> >  Get SDR Repository Info Request
> >
> > =
> >
> > KCS Header:
> >
> > 
> >
> > [   0h] = lun[ 2b]
> >
> > [   Ah] = net_fn[ 6b]
> >
> > IPMI Command Data:
> >
> > --
> >
> > [  20h] = cmd[ 8b]
> >
> > (ipmi_monitoring_sdr_cache.c,
> ipmi_monitoring_sdr_cache_load, 314):
> > ipmi_sdr_cache_open: internal IPMI error
> >
> > ipmi_monitoring_sensor_readings_by_record_id: internal error
> >
> >
> > 2)
> >
> > a) Failed right away (first sdr request in the trace)
> >
> >  =
> >
> > Get SDR Repository Info Request
> >
> > =
> >
> > KCS Header:
> >
> > 
> >
> > [   0h] = lun[ 2b]
> >
> > [   Ah] = net_fn[ 6b]
> >
> > IPMI Command Data:
> >
> > --
> >
> > [  20h] = cmd[ 8b]
> >
> > (ipmi_monitoring_sdr_cache.c,
> _ipmi_monitoring_sdr_cache_retrieve,
> > 223): ipmi_sdr_cache_create: internal IPMI error
> >
> > ipmi_monitoring_sensor_readings_by_record_id: internal error
> >
> >
> > b) Failed after going though some sdr requests
> >
> > =
> >
> > Get SDR Request
> >
> > =
> >
> > KCS Header:
> >
> > 
> >
> > [   0h] = lun[ 2b]
> >
> > [   Ah] = net_fn[ 6b]
> >
> > IPMI Command Data:
> >
> > --
> >
> > [  23h] = cmd[ 8b]
> >
> > [8820h] = reservation_id[16b]
> >
> > [  82h] = record_id[16b]
> 

Re: [Freeipmi-devel] ipmi_monitoring_sensor_readings_by_record_id: internal error

[Albert Chu]

=
> 
> Get Sensor Reading Request
> 
> =
> 
> KCS Header:
> 
> 
> 
> [   0h] = lun[ 2b]
> 
> [   4h] = net_fn[ 6b]
> 
> IPMI Command Data:
> 
> --
> 
> [  2Dh] = cmd[ 8b]
> 
> [  90h] = sensor_number[ 8b]
> 
> =
> 
> Get Sensor Reading Response
> 
> =========
> 
> KCS Header:
> 
> 
> 
> [   0h] = lun[ 2b]
> 
> [   5h] = net_fn[ 6b]
> 
> IPMI Command Data:
> 
> --
> 
> [   0h] = cmd[ 8b]
> 
> (ipmi_monitoring_sensor_reading.c, _get_sensor_reading, 356):
> ipmi_sensor_read: internal IPMI error
> 
> (ipmi_monitoring.c, _ipmi_monitoring_sensor_readings_by_record_id,
> 1449): ipmi_sdr_cache_iterate: error returned in callback
> 
> ipmi_monitoring_sensor_readings_by_record_id: internal error
> 
> 
> Thanks
> 
> 
> 
> On Mon, Jul 17, 2017 at 11:46 PM, Albert Chu <achu.de...@gmail.com>
> wrote:
> Hi,
> 
> 
> What version of FreeIPMI are you using?  The line numbers
> don't quite line up with the master branch.
> 
> 
> Also, could you set IPMI_MONITORING_FLAGS_DEBUG_IPMI_PACKETS
> and show the IPMI packet that occurs right before the error
> line?
> 
> 
> Thanks,
> 
> 
> 
> Al
> 
> 
> On Mon, Jul 17, 2017 at 4:28 PM, Sohan Chowdary Kollu
> <sko...@ncsu.edu> wrote:
> Hi Albert,
> 
> Thanks for quick response. I have set the flags for
> debugging and found it failing at one of the three
> instances below in different runs.
> 
> 1) (ipmi_monitoring_sensor_reading.c,
> _get_sensor_reading, 356): ipmi_sensor_read: internal
> system error(ipmi_monitoring.c,
> _ipmi_monitoring_sensor_readings_by_record_id, 1449):
> ipmi_sdr_cache_iterate: error returned in callback
> ipmi_monitoring_sensor_readings_by_record_id: internal
> error
> 2)(ipmi_monitoring_sdr_cache.c,
> ipmi_monitoring_sdr_cache_load, 314):
> ipmi_sdr_cache_open: internal IPMI
> error ipmi_monitoring_sensor_readings_by_record_id:
> internal error
> 
> 
> 3) (ipmi_monitoring_sdr_cache.c,
> _ipmi_monitoring_sdr_cache_retrieve, 223):
> ipmi_sdr_cache_create: internal IPMI
> error ipmi_monitoring_sensor_readings_by_record_id:
> internal error
> 
> 
> 
> Thanks
> 
> 
> 
> On Mon, Jul 17, 2017 at 2:34 PM, Albert Chu
> <ch...@llnl.gov> wrote:
> The "internal error" indicates some logical
> error that the library
> doesn't know how to handle.  Given its coming
> from
> ipmi_monitoring_sensor_readings_by_record_id
> and it occurs when you run
> the program back to back, I would bet there is
> some internal IPMI issue
> on your system.  Perhaps its a new error code
> or something like that
> that I do not handle gracefully correctly.
> 
> To try and debug, could you set the flag
> "IPMI_MONITORING_FLAGS_DEBUG |
> IPMI_MONITORING_FLAGS_DEBUG_IPMI_PACKETS" when
> calling
> ipmimonitoring_init() in the example code.
> Hopefully that'll be enough
> to figure out the issue.
> 
> Al
> 
> On Mon, 2017-07-17 at 13:03 -0700, Sohan
> Chowdary Kollu wrote:
> > Hi,
> >
> > I am executi

Re: [Freeipmi-devel] ipmi_monitoring_sensor_readings_by_record_id: internal error

[Albert Chu]

Hi,

What version of FreeIPMI are you using?  The line numbers don't quite line
up with the master branch.

Also, could you set IPMI_MONITORING_FLAGS_DEBUG_IPMI_PACKETS and show the
IPMI packet that occurs right before the error line?

Thanks,

Al

On Mon, Jul 17, 2017 at 4:28 PM, Sohan Chowdary Kollu <sko...@ncsu.edu>
wrote:

> Hi Albert,
>
> Thanks for quick response. I have set the flags for debugging and found it
> failing at one of the three instances below in different runs.
>
> 1) (ipmi_monitoring_sensor_reading.c, _get_sensor_reading, 356):
> ipmi_sensor_read: internal system error(ipmi_monitoring.c,
> _ipmi_monitoring_sensor_readings_by_record_id, 1449):
> ipmi_sdr_cache_iterate: error returned in callback 
> ipmi_monitoring_sensor_readings_by_record_id:
> internal error
>
> 2)(ipmi_monitoring_sdr_cache.c, ipmi_monitoring_sdr_cache_load, 314):
> ipmi_sdr_cache_open: internal IPMI error 
> ipmi_monitoring_sensor_readings_by_record_id:
> internal error
>
> 3) (ipmi_monitoring_sdr_cache.c, _ipmi_monitoring_sdr_cache_retrieve,
> 223): ipmi_sdr_cache_create: internal IPMI error 
> ipmi_monitoring_sensor_readings_by_record_id:
> internal error
>
>
> Thanks
>
> On Mon, Jul 17, 2017 at 2:34 PM, Albert Chu <ch...@llnl.gov> wrote:
>
>> The "internal error" indicates some logical error that the library
>> doesn't know how to handle.  Given its coming from
>> ipmi_monitoring_sensor_readings_by_record_id and it occurs when you run
>> the program back to back, I would bet there is some internal IPMI issue
>> on your system.  Perhaps its a new error code or something like that
>> that I do not handle gracefully correctly.
>>
>> To try and debug, could you set the flag "IPMI_MONITORING_FLAGS_DEBUG |
>> IPMI_MONITORING_FLAGS_DEBUG_IPMI_PACKETS" when calling
>> ipmimonitoring_init() in the example code.  Hopefully that'll be enough
>> to figure out the issue.
>>
>> Al
>>
>> On Mon, 2017-07-17 at 13:03 -0700, Sohan Chowdary Kollu wrote:
>> > Hi,
>> >
>> > I am executing the ipmimonitoring-sensors.c example provided in the
>> > freeipmi library. It throws internal error sometimes. Issue is
>> > reproducible when i execute the program back to back couple of times.
>> > I need to wait approximately 30 sec or more after the last execution
>> > for the program to run properly.
>> >
>> >
>> > This is the error ipmi_monitoring_sensor_readings_by_record_id:
>> > internal error
>> >
>> >
>> >
>> > I ran some of the commands on terminal back to back , including
>> > ipmi-sensors with group option, ipmimonitoring etc. None of them thew
>> > any errors. Error occurs only when i am use the API.
>> >
>> >
>> > Has anyone faced this issue before? If yes, can you tell me how to
>> > avoid it
>> >
>> >
>> >
>> >
>> > Thanks,
>> > Sohan
>> > ___
>> > Freeipmi-devel mailing list
>> > Freeipmi-devel@gnu.org
>> > https://lists.gnu.org/mailman/listinfo/freeipmi-devel
>>
>> --
>> Albert Chu
>> ch...@llnl.gov
>> Computer Scientist
>> High Performance Systems Division
>> Lawrence Livermore National Laboratory
>>
>>
>>
>
>
> --
> Thanks,
> Sohan
>
> ___
> Freeipmi-devel mailing list
> Freeipmi-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/freeipmi-devel
>
>
___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/freeipmi-devel

Re: [Freeipmi-devel] ipmi_monitoring_sensor_readings_by_record_id: internal error

[Albert Chu]

The "internal error" indicates some logical error that the library
doesn't know how to handle.  Given its coming from
ipmi_monitoring_sensor_readings_by_record_id and it occurs when you run
the program back to back, I would bet there is some internal IPMI issue
on your system.  Perhaps its a new error code or something like that
that I do not handle gracefully correctly.

To try and debug, could you set the flag "IPMI_MONITORING_FLAGS_DEBUG |
IPMI_MONITORING_FLAGS_DEBUG_IPMI_PACKETS" when calling
ipmimonitoring_init() in the example code.  Hopefully that'll be enough
to figure out the issue.

Al

On Mon, 2017-07-17 at 13:03 -0700, Sohan Chowdary Kollu wrote:
> Hi,
> 
> I am executing the ipmimonitoring-sensors.c example provided in the
> freeipmi library. It throws internal error sometimes. Issue is
> reproducible when i execute the program back to back couple of times.
> I need to wait approximately 30 sec or more after the last execution
> for the program to run properly. 
> 
> 
> This is the error ipmi_monitoring_sensor_readings_by_record_id:
> internal error
> 
> 
> 
> I ran some of the commands on terminal back to back , including
> ipmi-sensors with group option, ipmimonitoring etc. None of them thew
> any errors. Error occurs only when i am use the API.
> 
> 
> Has anyone faced this issue before? If yes, can you tell me how to
> avoid it
> 
> 
> 
>  
> Thanks,
> Sohan
> ___
> Freeipmi-devel mailing list
> Freeipmi-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/freeipmi-devel

-- 
Albert Chu
ch...@llnl.gov
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory



___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/freeipmi-devel

[Freeipmi-devel] [bug #51433] Freeipmi manpage display upper case version for command examples

[Albert Chu]

Update of bug #51433 (project freeipmi):

 Open/Closed:Open => Closed 


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/freeipmi-devel

[Freeipmi-devel] [bug #51433] Freeipmi manpage display upper case version for command examples

[Albert Chu]

Follow-up Comment #1, bug #51433 (project freeipmi):

Thanks.  I'm gonna fix it up in a bunch of other places too.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/freeipmi-devel

[Freeipmi-devel] FreeIPMI 1.5.6

[Albert Chu]

http://ftp.gnu.org/gnu/freeipmi/freeipmi-1.5.6.tar.gz

FreeIPMI 1.5.6 - 07/05/17
-
o In libfreeipmi locate (used by ipmi-locate), use DMI firmware in
  sysfs if it exists.
o Minor mem-leak corner case fix in libfreeipmi.
o Minor documentation fixes.
o Minor error message clarifications.

Al

-- 
Albert Chu
ch...@llnl.gov
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory



___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/freeipmi-devel

Re: [Freeipmi-devel] [PATCH] Using DMI firmware in sysfs if exists

[Albert Chu]

It seems important, so I'll put a release on my todo queue.

Al

On Wed, 2017-06-28 at 11:16 +0800, Ike Panhc wrote:
> Hi Albert,
> 
> Thanks for feedback.
> 
> You are the one to make the call. and I believe it
> is good to have a new release so every distro can
> have this fix especially they have arm64 release.
> 
> --
> Ike Panhc
> 
> 
> On 06/28/2017 07:42 AM, Albert Chu wrote:
> > LGTM, thanks!  This seems important/serious enough that it would affect
> > current users.  Do you think a new release is warranted?
> > 
> > Al
> > 
> > On Tue, 2017-06-27 at 16:07 +0800, Ike Panhc wrote:
> >> On arm64 system scanning /dev/mem for SMBIOS tables might fail and
> >> stopped with SIGBUS. Kernel version > 4.2 provides DMI tables in
> >> /sys/firmware/dmi/tables and it is much safer for ipmi-locate to
> >> read. If it exists, reading from it instead of /dev/mem fix
> >> ipmi-locate crash on several arm64 system.
> >>
> >> Unfortunately mmap() does not work on DMI tables so also fallback to
> >> read if mmap() failed.
> >>
> >> Signed-off-by: Ike Panhc <ike@canonical.com>
> >> ---
> >>  libfreeipmi/locate/ipmi-locate-dmidecode.c | 28 
> >> +++-
> >>  1 file changed, 23 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/libfreeipmi/locate/ipmi-locate-dmidecode.c 
> >> b/libfreeipmi/locate/ipmi-locate-dmidecode.c
> >> index 8a89fc0..db1c473 100644
> >> --- a/libfreeipmi/locate/ipmi-locate-dmidecode.c
> >> +++ b/libfreeipmi/locate/ipmi-locate-dmidecode.c
> >> @@ -115,7 +115,6 @@ struct dmi_header
> >>fipmiu16 handle;
> >>  };
> >>  
> >> -#ifndef HAVE_MMAP
> >>  static int
> >>  _myread (ipmi_locate_ctx_t ctx,
> >>   int fd,
> >> @@ -155,7 +154,6 @@ _myread (ipmi_locate_ctx_t ctx,
> >>  
> >>return (0);
> >>  }
> >> -#endif
> >>  
> >>  static int
> >>  _checksum (const fipmiu8 *buf, size_t len)
> >> @@ -233,14 +231,16 @@ _mem_chunk (ipmi_locate_ctx_t ctx,
> >> base - mmoffset)) == MAP_FAILED)
> >>  {
> >>LOCATE_ERRNO_TO_LOCATE_ERRNUM (ctx, errno);
> >> -  goto cleanup;
> >> +  goto try_read;
> >>  }
> >>  
> >>memcpy (p, (fipmiu8 *) mmp + mmoffset, len);
> >>rv = p;
> >>/* ignore potential error, just return result */
> >>munmap (mmp, mmoffset + len);
> >> -#else /* HAVE_MMAP */
> >> +  goto cleanup;
> >> + try_read:
> >> +#endif /* HAVE_MMAP */
> >>  
> >>if (lseek (fd, base, SEEK_SET) < 0)
> >>  {
> >> @@ -252,7 +252,6 @@ _mem_chunk (ipmi_locate_ctx_t ctx,
> >>  goto cleanup;
> >>  
> >>rv = p;
> >> -#endif /* HAVE_MMAP */
> >>  
> >>   cleanup:
> >>/* ignore potential error, cleanup path */
> >> @@ -457,6 +456,8 @@ ipmi_locate_dmidecode_get_device_info 
> >> (ipmi_locate_ctx_t ctx,
> >>char linebuf[64];
> >>fipmiu8 *buf = NULL;
> >>int rv = -1;
> >> +  static char const sys_fw_dmi_tables[] = "/sys/firmware/dmi/tables/DMI";
> >> +  struct stat st;
> >>  
> >>if (!ctx || ctx->magic != IPMI_LOCATE_CTX_MAGIC)
> >>  {
> >> @@ -471,6 +472,23 @@ ipmi_locate_dmidecode_get_device_info 
> >> (ipmi_locate_ctx_t ctx,
> >>  }
> >>  
> >>memset (_info, '\0', sizeof (struct ipmi_locate_info));
> >> +
> >> +  /* if DMI firmware exist, use it and do not dig into /dev/mem */
> >> +  if (!(stat (sys_fw_dmi_tables, )))
> >> +{
> >> +  rv = _dmi_table (ctx,
> >> +0,
> >> +st.st_size,
> >> +st.st_size / 4,
> >> +0,
> >> +sys_fw_dmi_tables,
> >> +type,
> >> +_info);
> >> +  if (!(rv))
> >> +memcpy (info, _info, sizeof (struct ipmi_locate_info));
> >> +  return (rv);
> >> +}
> >> +
> >>/*
> >> * Linux up to 2.6.6-rc2: /proc/efi/systab
> >> * Linux 2.6.6-rc3 and up: /sys/firmware/efi/systab
> > 
> 

-- 
Albert Chu
ch...@llnl.gov
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory



___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/freeipmi-devel

Re: [Freeipmi-devel] [PATCH] Using DMI firmware in sysfs if exists

[Albert Chu]

LGTM, thanks!  This seems important/serious enough that it would affect
current users.  Do you think a new release is warranted?

Al

On Tue, 2017-06-27 at 16:07 +0800, Ike Panhc wrote:
> On arm64 system scanning /dev/mem for SMBIOS tables might fail and
> stopped with SIGBUS. Kernel version > 4.2 provides DMI tables in
> /sys/firmware/dmi/tables and it is much safer for ipmi-locate to
> read. If it exists, reading from it instead of /dev/mem fix
> ipmi-locate crash on several arm64 system.
> 
> Unfortunately mmap() does not work on DMI tables so also fallback to
> read if mmap() failed.
> 
> Signed-off-by: Ike Panhc <ike@canonical.com>
> ---
>  libfreeipmi/locate/ipmi-locate-dmidecode.c | 28 +++-
>  1 file changed, 23 insertions(+), 5 deletions(-)
> 
> diff --git a/libfreeipmi/locate/ipmi-locate-dmidecode.c 
> b/libfreeipmi/locate/ipmi-locate-dmidecode.c
> index 8a89fc0..db1c473 100644
> --- a/libfreeipmi/locate/ipmi-locate-dmidecode.c
> +++ b/libfreeipmi/locate/ipmi-locate-dmidecode.c
> @@ -115,7 +115,6 @@ struct dmi_header
>fipmiu16 handle;
>  };
>  
> -#ifndef HAVE_MMAP
>  static int
>  _myread (ipmi_locate_ctx_t ctx,
>   int fd,
> @@ -155,7 +154,6 @@ _myread (ipmi_locate_ctx_t ctx,
>  
>return (0);
>  }
> -#endif
>  
>  static int
>  _checksum (const fipmiu8 *buf, size_t len)
> @@ -233,14 +231,16 @@ _mem_chunk (ipmi_locate_ctx_t ctx,
> base - mmoffset)) == MAP_FAILED)
>  {
>LOCATE_ERRNO_TO_LOCATE_ERRNUM (ctx, errno);
> -  goto cleanup;
> +  goto try_read;
>  }
>  
>memcpy (p, (fipmiu8 *) mmp + mmoffset, len);
>rv = p;
>/* ignore potential error, just return result */
>munmap (mmp, mmoffset + len);
> -#else /* HAVE_MMAP */
> +  goto cleanup;
> + try_read:
> +#endif /* HAVE_MMAP */
>  
>if (lseek (fd, base, SEEK_SET) < 0)
>  {
> @@ -252,7 +252,6 @@ _mem_chunk (ipmi_locate_ctx_t ctx,
>  goto cleanup;
>  
>rv = p;
> -#endif /* HAVE_MMAP */
>  
>   cleanup:
>/* ignore potential error, cleanup path */
> @@ -457,6 +456,8 @@ ipmi_locate_dmidecode_get_device_info (ipmi_locate_ctx_t 
> ctx,
>char linebuf[64];
>fipmiu8 *buf = NULL;
>int rv = -1;
> +  static char const sys_fw_dmi_tables[] = "/sys/firmware/dmi/tables/DMI";
> +  struct stat st;
>  
>if (!ctx || ctx->magic != IPMI_LOCATE_CTX_MAGIC)
>  {
> @@ -471,6 +472,23 @@ ipmi_locate_dmidecode_get_device_info (ipmi_locate_ctx_t 
> ctx,
>  }
>  
>memset (_info, '\0', sizeof (struct ipmi_locate_info));
> +
> +  /* if DMI firmware exist, use it and do not dig into /dev/mem */
> +  if (!(stat (sys_fw_dmi_tables, )))
> +{
> +  rv = _dmi_table (ctx,
> +0,
> +st.st_size,
> +st.st_size / 4,
> +0,
> +sys_fw_dmi_tables,
> +    type,
> +_info);
> +  if (!(rv))
> +memcpy (info, _info, sizeof (struct ipmi_locate_info));
> +  return (rv);
> +}
> +
>/*
> * Linux up to 2.6.6-rc2: /proc/efi/systab
> * Linux 2.6.6-rc3 and up: /sys/firmware/efi/systab

-- 
Albert Chu
ch...@llnl.gov
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory



___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/freeipmi-devel

[Freeipmi-devel] [bug #51105] The script ganglia_ipmi_sensors.pl can break your entire Ganglia with buggy IPMI servers

[Albert Chu]

Follow-up Comment #1, bug #51105 (project freeipmi):

In principle a good idea.  Although I think it should output something to warn
the user.

if ($id_string =~ /[\x00-\x1F]/) {
print "something error message"
next;
}

Another alternate idea.  Perhaps the junk characters could be converted into
something readable?  Just spaces?  This would be great if the junk characters
are at the end of the string (i.e. vendor didn't NUL terminate whatever they
stuck in the firmware).

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/freeipmi-devel

Re: [Freeipmi-devel] freeipmi error

[Albert Chu]

Hi,

There's pretty much no information here.  What command?  What error?
Can you cut and paste output and with --debug info.

Al

On Fri, 2017-04-07 at 10:09 +, Pradnya Kapase wrote:
> After executing the command, I am getting the response message
> twice
> 
> 
> Please help me with this
> 
> 
> Regards
> 
> Sent from Yahoo Mail on Android
> ___
> Freeipmi-devel mailing list
> Freeipmi-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/freeipmi-devel

-- 
Albert Chu
ch...@llnl.gov
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory



___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/freeipmi-devel

[Freeipmi-devel] [sr #109207] system firmware event severity shows N/A

[Albert Chu]

Follow-up Comment #1, sr #109207 (project freeipmi):

I assume this is your own personal debugging from using the libipmimonitoring
library?

libipmimonitoring doesn't currently support "system firmware progress" as an
event it knows how to interpret.  That can be added into FreeIPMI.  Can you
please show the --debug output for this SEL event.  You can find it via

ipmi-sel --debug --display=SEL-RECORD-ID

However, I'm not sure how much this fix would matter.  Your event below
("0x0F") is actually not specified by the IPMI specification.  You'll probably
have to contact your vendor to figure out what the issue is.  It may be OEM
specific to them.







___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/freeipmi-devel

[Freeipmi-devel] [bug #49813] libfreeipmi crashes when using multithreading >1024 threads

[Albert Chu]

Follow-up Comment #2, bug #49813 (project freeipmi):

It's now in the master branch, should be out in the next major release.  If
you are interested it being backported to the stable line, PLMK

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/freeipmi-devel

[Freeipmi-devel] [bug #49813] libfreeipmi crashes when using multithreading >1024 threads

[Albert Chu]

Follow-up Comment #1, bug #49813 (project freeipmi):

In principle replacing select w/ poll is a good idea.  Would you be able to
supply a patch instead of the whole file?  Thanks.

Alternately, you could send a pull request to

https://github.com/chu11/freeipmi-mirror

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/freeipmi-devel

[Freeipmi-devel] FreeIPMI 1.5.5 Released

[Albert Chu]

http://ftp.gnu.org/gnu/freeipmi/freeipmi-1.5.5.tar.gz

FreeIPMI 1.5.5 - 11/02/16
-
o Fix invalid flag clear in libipmiconsole that can lead to a potential
  double close on a file descriptor.
o Support Supermicro H8SGL-F OEM sensors and events.

Al

-- 
Albert Chu
ch...@llnl.gov
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory



___
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/freeipmi-devel