i2c and lm-sensors
 

Hi,

I'd like to install lm-sensors but apparently I need the libsysfs development package in order to do this. I started the compile from source, but it croaks with an error - requiring libsysfs development headers.

It doesn't seem to be in the list of packages. Am I right, or is its name disguised a bit?
Or if doing it myself is something I could do (ie. a reasonably simple compile job) just tell me where to find the source package and I'll get on with it.

Thanks in advance,
Simon.

libsysfs is part of the sysfsutils package. Source and packages at Sourceforge

Thanks for that. sysfsutils is included in the Grafpup repository, but see below.

OK, this is where I've got to... it may help others. I am using a EPIA M10000 mobo so the sensors obviously differ for other brands/models.


I initially tried sysfsutils from the Grafpup repository, but perhaps something was missing as it didn't make any difference to the success of making the lm-sensors package.

Anyways, I downloaded sysfsutils-2.1.0 from Sourceforge and compiled that with "./configure ; make ; make install and it all worked.

Then I edited the Makefile for lm-sensors as there's a modification to make for 2.6 and up kernels. You have to uncomment a definition.

'make clean ; make user' then worked.
'make install_user'

modprobe-i2c complained that there were no i2c device files, and that you should run (from the lm_sensors directory) 'prog/mkdev/mkdev.sh'

So I ran mkdev.sh, and it created a lot of new devices. Then /usr/sbin/sensors-detect worked successfully, detecting my EPIA M10000 on-board sensors.

insmod i2c-viapro worked.
modprobe eeprom worked
modprobe vt1211 did not work - this apparently is bleeding edge stuff with the 2.6.x kernels.

Nathan, is the module vt1211 in the zdrv.sfs ?

I would have a look but accessing files in the root of the cf-card I boot from, is something I've not fathomed out. I saw how you helped Mike Sumner with a mount ... loop etc but my problem is expressing where the zdrv.sys actually *is*.....

Hopefully it's there, but if not, I hope the state of flux of vt1211 and the 2.6.x kernels doesn't cause problems.

Simon

I've been digging.

In grafpup.config (Nathan I bet you thought no-one would look in there!) it says CONFIG_SENSORS_VT1211 is not set.

Does that matter to me, as will vt1211 be loaded from the Zdrv? Was it done due to the 'bleeding edge' status of the vt1211 and 2.6.x kernels? I understand kernel configs very little indeed.

But hopefully I'm giving enough info to save Nathan some time.

Cheers,
Simon.

Well if I didn't want people to see it I wouldn't have made it available (grafpup.config). Basically when looking at the kernel config, not set means not compiled at all, y means compiled into the kernel, and m means compiled as a module. It should be possible to compile the module later on, which is what you may need to do.

I don't like to enable things that are labeled experimental when I'm compiling a kernel for others, for obvious reasons. Sorry.

Nathan

I was so pleased with myself when I found it, it's the first time I've dug around in kernel configs.

Some time in the future I will experiment with recompiling the kernel. Not right now though :-)

Totally understood, thanks.

I've moved forward a bit on this one. Below follows a summary of compiling the necessary modules locally and inserting them to the running kernel. (This stuff is very new to me...!) I have no plans to recompile the kernel to add them permanently, rather I'm loading them in the later stages of the boot process.

My mobo is an EPIA M10000 LVDS. It uses a vt1211 chip for the temperature sensors and fans, the driver for which was not 'solidly reliable' for use in the kernel 2.6.20. The chip lives on the isa bus at address 6000.

To get lm-sensors to work (more specifically, the 'sensors' command) I needed the vt1211 module.

I got a good push down this path from here: http://markus.dolic.com/2005/09/13/lm_sensors-on-epia-ml8000a/#more-23

So I begun by getting the 2.6.20.2 kernel source tarball from kernel.org. This is exactly the kernel version used in Grafpup r2.00.

I extracted the drivers/hwmon/vt1211.c source file into a local directory (I used /usr/src/linux/local-vt1211).
In that directory, following these instructions http://www.cyberciti.biz/tips/print.php?p=385&print=1
I created a Makefile containing this:
... and then compiled:
There was a script error, but I pressed on anyway.
The result was a file 'vt1211.ko' which was exactly what I wanted (to do insmod/modprobe with).

Now I could 'insmod' the module, well almost, because it complained about missing symbols. These were due to a dependency on the modules hwmod.ko and hwmon-vid.ko
so I extracted those two and repeated the compilation process (in their own local directories, with different module names in the Makefiles too).

Finally I could do:

Feeling very pleased with myself I typed 'sensors':
Excellent!

I have copied the built .ko modules into the modprobe search directory path (actually '/lib/modules/2.6.20.2/devices/hwmon') and then loading lm_sensors in /etc/rc.d/rc.services works at every boot now.

I have to tweak, or locate a tweaked sensors.conf file for the M10000, as some of the scalings are wrong. Look at the temp1 for example.

In the short time that I've used it, the driver seems to work <for me>. Until I've fixed all the scaling etc issues then I'm still not there -- but I have come a long way down the road :-)

Cheers,
Simon.

Excellent Simon, I'm very glad to hear it. Perhaps when all is said and done there could be a package containing the modules you have compiled, in case others want to try?

Nathan

Yep, be happy to. I will need to research how to create a package though. I presume what applies to Puppy, applies to Grafpup? So if I find tutorials on plain Puppy, they will be fine?

Finally I have CPU temperature output from 'sensors' .... which on my hardware was a merry dance indeed.

I have a EPIA M10000 LVDS, which has probably one of the most obscure CPU temp sensors in the world. The poor documentation and myriad of different info on the net kept me guessing.

I realise that everyone's hardware differs but posting the detail here might help others searching for help.

So where I left it, was that I had flawed temperature readings for the CPU of around 100 degrees. That was plainly not right as I could feel the heatsink and it was just warm.

The critical points in /etc/sensors.conf were:

1. The 3.3V was always wrong. It seems that on my motherboard the internal 3.3V is used, which means that no 'compute' line is required for in5.

2. The correct CPU temperature is on channel temp1 (not temp3 as it was re-named, apparently). Channel temp3 does not exist in the /sys/devices/platform/vt1211.24576 directory with all the other files.
Outputting the raw data from the file temp1_input gives me 105000. So you can see how readings of 105 degrees occurred.

3. A better compute line was necessary to get a realistic temperature figure. I have used one originally from Guido Brunner (BUT I renamed it to compute channel 1!):
... and that gives me 43 degrees C on the CPU in a domestic room at 21 degrees. Pretty good.

I will test that figure with the machine in a colder room soon.

The hysteresis numbers and alarm values are still quite wacky though. I can't seem to set any better limits.

I still get errors when lm_sensors starts, ie. "Can't access procfs/sysfs for writing. Run as root?"

I think the reason might be that on my board, the vt1211 lives in the sys filesystem at:
... which seems to be an unusual spot. Perhaps the driver is not expecting this? I will review the vt1211.c code to try and find out.

Edit: I've since written into in5_min and in5_max files to correct the 3.3V alarm thresholds. A simple echo <number> to the appropriate files did the trick.

Edit 2: The 'cannot access files for writing' was due to a "set config 12" in the sensors.conf. It appears that, on my board the BIOS sets the sensor chip configuration at boot time, and the user is not allowed to change it. Makes sense really. So I removed the 'set config 12' and no errors then occurred.

Just another note, to get the lm_sensors package to work, I had to get a copy of

/etc/init.d/functions

from somewhere. It only provides a couple of shell functions to make scripts' life easier. echo_success, echo_failure for two.

I have also seen it referenced by VNC.

So, it might be worth including in a future version. When I do a package for vt1211 stuff, I will include it.

Nathan, what would be the best package format to use? Dotput or pupget or something else? I need to know which to learn, thanks.

Dotpup is deprecated, if you want to create a package for general distribution please create either an unleashed tarball or a PET package (almost the same thing really). I'm still working on documentation but there is a skeleton up with a lot of information for developers at http://grafpup.org/docs/development.php

Finally, I've learned about the PET creation process and created some. (I could have picked easier packages to do!)

I'm not warranting that these will be 100% working, since it was a learning experience for me. It would be good for others to try them out and report any problems on this thread.

I have created PET packages for the following:

lm_sensors 2.10.3 including a sensors.conf file only for the VT1211 chip on VIA M10000 mobo

vt1211 kernel modules for 2.6.20.2 kernel (Grafpup 2.00final) and source code for recompilation

sysfsutils 2.1.0 & sysfsutils-dev 2.1.0 (should only be needed for recompilation)

The compilation target was set to i586 in line with the Grafpup standard. You should not need the 'devx' package to use these, although for recompilation it will be needed.

Since the packages did not use the standard ./configure script arrangement, I had to manually assemble all the components before PET-ing them. Anyone realising that there's a missing file, please do report ASAP as I can re-create the packages from my machine.

The packages only add files to an installation, they do not overwrite any, unless the same package has been installed before. They do register with PETget so can be removed.

You will need to ensure that the lm_sensors package is started on reboot, by adding a line to /etc/rc.d/rc.services containing:
The packages are hosted at:
lm_sensors-2.10.3.pet
kernel_vt1211-2.6.20.pet
lm_sensors-2.10.3.pet
sysfsutils_dev-2.1.0.pet

I look forward to any reports of success or failure!
Simon.