GrafpupThis forum is for the discussion of Grafpup Linux.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
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 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.
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.
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.
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.
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.
root@mantis # make
make -C /lib/modules/220.127.116.11/build SUBDIRS=/usr/src/linux-18.104.22.168/local-hwmon-vid modules
/bin/sh: /usr/src/linux-22.214.171.124/scripts/gcc-version.sh: No such file or directory
/bin/sh: line 0: [: -lt: unary operator expected
make: Entering directory `/usr/src/linux-126.96.36.199'
CC [M] /usr/src/linux-188.8.131.52/local-hwmon-vid/hwmon-vid.o
Building modules, stage 2.
MODPOST 1 modules
ls LD [M] /usr/src/linux-184.108.40.206/local-hwmon-vid/hwmon-vid.ko
-make: Leaving directory `/usr/src/linux-220.127.116.11'
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).
Feeling very pleased with myself I typed 'sensors':
root@mantis # sensors
Adapter: ISA adapter
VCore1: +1.42 V (min = -0.03 V, max = +2.71 V)
+5V: +5.34 V (min = -0.08 V, max = +7.14 V)
+12V: +12.37 V (min = -0.18 V, max = +15.47 V)
+3.3V: +5.42 V (min = -0.05 V, max = +6.88 V)
fan1: 4783 RPM (min = 0 RPM, div = 2)
fan2: 6971 RPM (min = 0 RPM, div = 2)
temp1: +100.0°C (high = +255°C, hyst = +0°C)
ERROR: Can't get TEMP2 data!
vid: +1.750 V (VRM Version 1.7)
I have copied the built .ko modules into the modprobe search directory path (actually '/lib/modules/18.104.22.168/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 :-)
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.
root@mantis # sensors
Adapter: ISA adapter
VCore: +1.41 V (min = +1.29 V, max = +1.42 V)
+5V: +5.20 V (min = +4.58 V, max = +5.26 V)
+12V: +12.89 V (min = +10.78 V, max = +13.21 V)
+3.3V: +3.30 V (min = +4.18 V, max = +4.18 V) ALARM
System: 4748 RPM (min = 1503 RPM, div = 4)
CPU: 6971 RPM (min = 3006 RPM, div = 2)
CPU-Temp: +44.3°C (high = +72°C, hyst = -1°C)
Sys-Temp: +43.0°C (high = +65°C, hyst = +91°C)
vid: +1.850 V (VRM Version 9.1)
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.
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 22.214.171.124 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: