[lm-sensors] ipmisensors module ported to 2.6.29

[lm-sensors] ipmisensors module ported to 2.6.29

[Paul Harper]

I have ported the ipmisensors module to kernel version 2.6.29 and
corrected the issues with fatal errors on loading and swizzling of
device data.  On my IBM development platform (3650) the module now works
as expected and data from ipmitool and lm-sensors is in sync.  

I then did a test on a SuperMicro chassis and the module could not
connect to the bmc.  ipmitool works as expected on the SuperMicro.  In
examination of the ipmitool code, it appears that they have moved to
IPMB comms rather than a direct connect to the BMC.

Before I start changing ipmisensors to use IPMB comms, is there another
preferred module to use when exposing sensors to lm-sensors and the
vendor provides impi support?

Paul Harper
paul.harper@arrisi.com 


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] ipmisensors module ported to 2.6.29

[Hans de Goede]

Hi,

On 11/18/2009 11:43 PM, Paul Harper wrote:
> I have ported the ipmisensors module to kernel version 2.6.29 and
> corrected the issues with fatal errors on loading and swizzling of
> device data.  On my IBM development platform (3650) the module now works
> as expected and data from ipmitool and lm-sensors is in sync.
>
> I then did a test on a SuperMicro chassis and the module could not
> connect to the bmc.  ipmitool works as expected on the SuperMicro.  In
> examination of the ipmitool code, it appears that they have moved to
> IPMB comms rather than a direct connect to the BMC.
>
> Before I start changing ipmisensors to use IPMB comms, is there another
> preferred module to use when exposing sensors to lm-sensors and the
> vendor provides impi support?
>

This is just my 2 cents, so before you actually act on this, it would be
good to get a second opinion, say Jean Delvare's .

Given that there already are various userspace options to reading ipmi
sensors, which I assume work as non root (iow no direct io banging). An
alternative to using a kernel driver might be the extend libsensors
to be able to read sensor info from other sources then the hwmon
sysfs interface.

what I envision is:
1) abstraction of sensor source enumeration and reading in libsensors
2) a plugin architecture to add support for different sensor sources
3) Various plugins for example:
    hwmon sysfs (of course)
    something to read harddisk temps using smart
    code to read ipmi info

I think this would be really nice to have as currently many applications
have support for both libsensors and have separate code for things like
harddisks temps, etc. libsensors seems like a logical place to consolidate
this.

I must warn though, that this will require some surgery to libsensors, it was
never designed to do this.

If you are willing to spend effort on this, I would be happy to help were I
can!

Regards,

Hans

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] ipmisensors module ported to 2.6.29

[Jean Delvare]

Hi Hans,

On Thu, 19 Nov 2009 10:56:29 +0100, Hans de Goede wrote:
> On 11/18/2009 11:43 PM, Paul Harper wrote:
> > I have ported the ipmisensors module to kernel version 2.6.29 and
> > corrected the issues with fatal errors on loading and swizzling of
> > device data.  On my IBM development platform (3650) the module now works
> > as expected and data from ipmitool and lm-sensors is in sync.
> >
> > I then did a test on a SuperMicro chassis and the module could not
> > connect to the bmc.  ipmitool works as expected on the SuperMicro.  In
> > examination of the ipmitool code, it appears that they have moved to
> > IPMB comms rather than a direct connect to the BMC.
> >
> > Before I start changing ipmisensors to use IPMB comms, is there another
> > preferred module to use when exposing sensors to lm-sensors and the
> > vendor provides impi support?
> 
> This is just my 2 cents, so before you actually act on this, it would be
> good to get a second opinion, say Jean Delvare's .
> 
> Given that there already are various userspace options to reading ipmi
> sensors, which I assume work as non root (iow no direct io banging). An
> alternative to using a kernel driver might be the extend libsensors
> to be able to read sensor info from other sources then the hwmon
> sysfs interface.
> 
> what I envision is:
> 1) abstraction of sensor source enumeration and reading in libsensors
> 2) a plugin architecture to add support for different sensor sources
> 3) Various plugins for example:
>     hwmon sysfs (of course)
>     something to read harddisk temps using smart
>     code to read ipmi info
> 
> I think this would be really nice to have as currently many applications
> have support for both libsensors and have separate code for things like
> harddisks temps, etc. libsensors seems like a logical place to consolidate
> this.

I agree. We have already managed to merge ACPI thermal zone support
into libsensors, by having the driver follow the standard sysfs
interface. Getting all the other sensor types supported by libsensors
would help reduce code duplication in end-user applications. Now,
whether this should be handled in libsensors or in the kernel... is an
open question.

For IPMI, I don't know if "ipmitool sensor" can be run as non-root,
this needs to be confirmed. I presume it depends on the permissions of
the /dev/impi* nodes.If sensors information can indeed be retrieved by
regular users, then it might be worth investigating. But we certainly
don't want to parse the output of "ipmitool sensor", so we would have
to copy the data retrieval code and convert the results to the
libsensors internal format.

We will have to duplicate code either way, be it in an ipmisensors
kernel module, or in libsensors. I presume the key question is where
the code duplication is cheaper and less risky. I have always wondered
if ipmisensors and "ipmitool sensor" were safe to use together.

For HDD temperature, I know you need to be root to access the data.
hddtemp is a ugly hack. I suspect it would be better to write a kernel
driver for this.

> I must warn though, that this will require some surgery to libsensors, it was
> never designed to do this.

I admit I am a little frightened, but OTOH, the libsensors 3 code is
much nicer than what we had in libsensors 2, it should be easier to
extend.

> If you are willing to spend effort on this, I would be happy to help were I
> can!

The bottom line is that anyone who pushes IPMI sensors support forward
has my blessing. Honestly, I don't care that much whether it is in the
kernel or in libsensors, as long as it finally happens. It has been
pending for sooooo long :(

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] ipmisensors module ported to 2.6.29

[Luca Tettamanti]

On Thu, Nov 19, 2009 at 11:46 AM, Jean Delvare <khali@linux-fr.org> wrote:
> For IPMI, I don't know if "ipmitool sensor" can be run as non-root,
> this needs to be confirmed. I presume it depends on the permissions of
> the /dev/impi* nodes.

Yes, the user needs rw permission on the device node.

>> If you are willing to spend effort on this, I would be happy to help were I
>> can!
>
> The bottom line is that anyone who pushes IPMI sensors support forward
> has my blessing. Honestly, I don't care that much whether it is in the
> kernel or in libsensors, as long as it finally happens. It has been
> pending for sooooo long :(

+1 ;-)
I have the hardware (a few Dell servers) so at least I can do testing
(and hopefully some coding).

L

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] ipmisensors module ported to 2.6.29

[Jean Delvare]

On Thu, 19 Nov 2009 12:22:39 +0100, Luca Tettamanti wrote:
> On Thu, Nov 19, 2009 at 11:46 AM, Jean Delvare <khali@linux-fr.org> wrote:
> > For IPMI, I don't know if "ipmitool sensor" can be run as non-root,
> > this needs to be confirmed. I presume it depends on the permissions of
> > the /dev/impi* nodes.
> 
> Yes, the user needs rw permission on the device node.
> 
> >> If you are willing to spend effort on this, I would be happy to help were I
> >> can!
> >
> > The bottom line is that anyone who pushes IPMI sensors support forward
> > has my blessing. Honestly, I don't care that much whether it is in the
> > kernel or in libsensors, as long as it finally happens. It has been
> > pending for sooooo long :(
> 
> +1 ;-)
> I have the hardware (a few Dell servers) so at least I can do testing
> (and hopefully some coding).

Would you be willing to work together with Paul to put ipmisensors code
into shape to be finally merged into the kernel? After it is confirmed
that ipmisensors won't cause trouble to ipmisensors, of course.

Then we can discuss whether a libsensors-based implementation would
make sense, but if you need rw access to /dev/ipmi0 then I guess a
user-space implementation becomes unrealistic.

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] ipmisensors module ported to 2.6.29

[Luca Tettamanti]

On Thu, Nov 19, 2009 at 1:09 PM, Jean Delvare <khali@linux-fr.org> wrote:
> On Thu, 19 Nov 2009 12:22:39 +0100, Luca Tettamanti wrote:
>> On Thu, Nov 19, 2009 at 11:46 AM, Jean Delvare <khali@linux-fr.org> wrote:
>> > For IPMI, I don't know if "ipmitool sensor" can be run as non-root,
>> > this needs to be confirmed. I presume it depends on the permissions of
>> > the /dev/impi* nodes.
>>
>> Yes, the user needs rw permission on the device node.
>>
>> >> If you are willing to spend effort on this, I would be happy to help were I
>> >> can!
>> >
>> > The bottom line is that anyone who pushes IPMI sensors support forward
>> > has my blessing. Honestly, I don't care that much whether it is in the
>> > kernel or in libsensors, as long as it finally happens. It has been
>> > pending for sooooo long :(
>>
>> +1 ;-)
>> I have the hardware (a few Dell servers) so at least I can do testing
>> (and hopefully some coding).
>
> Would you be willing to work together with Paul to put ipmisensors code
> into shape to be finally merged into the kernel? After it is confirmed
> that ipmisensors won't cause trouble to ipmisensors, of course.

I _might_ be able to hijack a development machine during the weekend,
otherwise for testing I'd have to backport to 2.6.26 (Debian) since I
really can't do a lot of reboots to test a kernel module.

> Then we can discuss whether a libsensors-based implementation would
> make sense, but if you need rw access to /dev/ipmi0 then I guess a
> user-space implementation becomes unrealistic.

But easier to test for me :P
BTW, I did a quick recompile of ipmitool opening the device node ro:
it still works (or at least it seems to).

Luca

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] ipmisensors module ported to 2.6.29

[Jean Delvare]

On Thu, 19 Nov 2009 13:35:40 +0100, Luca Tettamanti wrote:
> On Thu, Nov 19, 2009 at 1:09 PM, Jean Delvare <khali@linux-fr.org> wrote:
> > Would you be willing to work together with Paul to put ipmisensors code
> > into shape to be finally merged into the kernel? After it is confirmed
> > that ipmisensors won't cause trouble to ipmisensors, of course.
> 
> I _might_ be able to hijack a development machine during the weekend,
> otherwise for testing I'd have to backport to 2.6.26 (Debian) since I
> really can't do a lot of reboots to test a kernel module.

OK.

> > Then we can discuss whether a libsensors-based implementation would
> > make sense, but if you need rw access to /dev/ipmi0 then I guess a
> > user-space implementation becomes unrealistic.
> 
> But easier to test for me :P
> BTW, I did a quick recompile of ipmitool opening the device node ro:
> it still works (or at least it seems to).

This is interesting. Maybe some commands need RW and some are fine with
read-only? In that case, ipmitool should be modified to only require
write access when it really needs it. Anyway, if sensor access doesn't
require write access then a libsensors-based implementation becomes
possible.

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] ipmisensors module ported to 2.6.29

[Philip Pokorny]

Anyone with rw permission on the ipmi device can tell the bmc to turn  
off the power to the server, change sensor limits, and BIOS settings  
in some cases

Access to ipmi isn't something ordinary users should have.

Phil P.

-- 
Philip Pokorny, RHCE
Chief Hardware Architect
PENGUIN COMPUTING, Inc
www.penguincomputing.com

On Nov 19, 2009, at 6:24 AM, "Luca Tettamanti" <kronos.it@gmail.com>  
wrote:

> On Thu, Nov 19, 2009 at 11:46 AM, Jean Delvare <khali@linux-fr.org>  
> wrote:
>> For IPMI, I don't know if "ipmitool sensor" can be run as non-root,
>> this needs to be confirmed. I presume it depends on the permissions  
>> of
>> the /dev/impi* nodes.
>
> Yes, the user needs rw permission on the device node.
>
>>> If you are willing to spend effort on this, I would be happy to  
>>> help were I
>>> can!
>>
>> The bottom line is that anyone who pushes IPMI sensors support  
>> forward
>> has my blessing. Honestly, I don't care that much whether it is in  
>> the
>> kernel or in libsensors, as long as it finally happens. It has been
>> pending for sooooo long :(
>
> +1 ;-)
> I have the hardware (a few Dell servers) so at least I can do testing
> (and hopefully some coding).
>
> L
>
> _______________________________________________
> lm-sensors mailing list
> lm-sensors@lm-sensors.org
> http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] ipmisensors module ported to 2.6.29

[Paul Harper]

Wow, quick responses.  I wasn't sure what to expect since the last
postings on this topic were about a year ago.

I can provide you with the code that I have now, but since I only have
it functional on one platform I don't believe it is ready for inclusion
in the kernel. It fails to load sensors on SuperMicro and unloading the
module is not yet clean (it leaves pieces of the sysfs structure it
creates).

If I can attempt a high-level summary of what I have read in this
thread:

  - there is currently no better alternative to ipmisensors
  - there is interest in this functionality either via ipmitool,
ipmisensors, or other yet to be created code
  - there is a desire to not replicate code

Based on this, I'll move forward with changing ipmisensors to use IPMB.
While this may not be a final solution and it will replicate some code,
it will provide access to the sensor data via lm-sensors (and in turn,
via net-snmp) and fits into the infrastructure as it exists today.

Paul Harper
paul.harper@arrisi.com 

On Thu, 2009-11-19 at 04:35 -0800, Luca Tettamanti wrote:
> On Thu, Nov 19, 2009 at 1:09 PM, Jean Delvare <khali@linux-fr.org> wrote:
> > On Thu, 19 Nov 2009 12:22:39 +0100, Luca Tettamanti wrote:
> >> On Thu, Nov 19, 2009 at 11:46 AM, Jean Delvare <khali@linux-fr.org> wrote:
> >> > For IPMI, I don't know if "ipmitool sensor" can be run as non-root,
> >> > this needs to be confirmed. I presume it depends on the permissions of
> >> > the /dev/impi* nodes.
> >>
> >> Yes, the user needs rw permission on the device node.
> >>
> >> >> If you are willing to spend effort on this, I would be happy to help were I
> >> >> can!
> >> >
> >> > The bottom line is that anyone who pushes IPMI sensors support forward
> >> > has my blessing. Honestly, I don't care that much whether it is in the
> >> > kernel or in libsensors, as long as it finally happens. It has been
> >> > pending for sooooo long :(
> >>
> >> +1 ;-)
> >> I have the hardware (a few Dell servers) so at least I can do testing
> >> (and hopefully some coding).
> >
> > Would you be willing to work together with Paul to put ipmisensors code
> > into shape to be finally merged into the kernel? After it is confirmed
> > that ipmisensors won't cause trouble to ipmisensors, of course.
> 
> I _might_ be able to hijack a development machine during the weekend,
> otherwise for testing I'd have to backport to 2.6.26 (Debian) since I
> really can't do a lot of reboots to test a kernel module.
> 
> > Then we can discuss whether a libsensors-based implementation would
> > make sense, but if you need rw access to /dev/ipmi0 then I guess a
> > user-space implementation becomes unrealistic.
> 
> But easier to test for me :P
> BTW, I did a quick recompile of ipmitool opening the device node ro:
> it still works (or at least it seems to).
> 
> Luca


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] ipmisensors module ported to 2.6.29

[Luca Tettamanti]

On Thu, Nov 19, 2009 at 7:46 PM, Paul Harper <paul.harper@arrisi.com> wrote:
> Based on this, I'll move forward with changing ipmisensors to use IPMB.
> While this may not be a final solution and it will replicate some code,
> it will provide access to the sensor data via lm-sensors (and in turn,
> via net-snmp) and fits into the infrastructure as it exists today.

Hi Paul,
any news on the driver? Is your code available somewhere?

L

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors