accessing temperatures under Slackware

I have been trying to access bios info regarding temperatures under my Slackware 13.37 OS.
I first looked at /proc/acpi/processor/CPU0/throttling where I found my active state to be T0 and my state count is 16. My understanding is that T0 is 100% throttling of either the CPU fan or the processor and the state count is meaningless to me.
I turned to the lm_sensors then. What I have been able to learn from sensors-detect is that my module should be w83627hf and this is a module (which I loaded via modprobe) and it is an available module.
Then I built /etc/sysconfig/lm_sensors but when it came to starting the sensors I learned only that it could be done via:
/etc/rc.d/init.d/lm_sensors start but init.d is rc.d?? Apparently, I am missing information or have taken an incorrect tack.
Can someone clear my fog about what it is I am reading under /proc and how to start the lm_sensors under Slackware?
Tnanks

---------- Post updated at 03:28 AM ---------- Previous update was at 02:18 AM ----------

By accident or perseverance I have most of the answer.
The sequence I took (the accident) was to run:
sensors -s <my_chip_set>
then per the man page (I do use them)
sensors --bus-list
To verify my results I found "HWMON_MODULES" in my config file:
cat /etc/sysconfig/lm_sensors yielded:
# Generated by sensors-detect on Sat Jul 28 00:54:55 2012
# This file is sourced by /etc/init.d/lm_sensors and defines the modules to
# be loaded/unloaded.
#
# The format of this file is a shell script that simply defines variables:
# HWMON_MODULES for hardware monitoring driver modules, and optionally
# BUS_MODULES for any required bus driver module (for example for I2C or SPI).

HWMON_MODULES="w83627hf"

# For compatibility reasons, modules are also listed individually as variables
# MODULE_0, MODULE_1, MODULE_2, etc.
# You should use BUS_MODULES and HWMON_MODULES instead if possible.

MODULE_0=w83627hf

I then ran:
sensors
and got:
w83697hf-isa-0290
Adapter: ISA adapter
in0: +1.68 V (min = +1.70 V, max = +2.53 V) ALARM
in2: +3.28 V (min = +4.05 V, max = +3.94 V) ALARM
in3: +3.01 V (min = +4.08 V, max = +2.38 V) ALARM
in4: +3.22 V (min = +1.26 V, max = +3.79 V)
in5: +0.61 V (min = +3.76 V, max = +1.26 V) ALARM
in6: +3.58 V (min = +4.08 V, max = +3.28 V) ALARM
in7: +3.28 V (min = +3.78 V, max = +1.94 V) ALARM
in8: +3.41 V (min = +4.05 V, max = +3.82 V) ALARM
fan1: 4787 RPM (min = 0 RPM, div = 2)
fan2: 0 RPM (min = 0 RPM, div = 4)
temp1: +40.0 C (high = -1.0 C, hyst = -1.0 C) ALARM sensor = thermistor
temp2: +40.5 C (high = +70.0 C, hyst = +67.0 C) sensor = thermistor
beep_enable:enabled

My recollection is that the AMD 2200+ is a single processor if so why do I have 2 temperatures??
Again thanks from a real happy camper

One of them may be the board temperature. Which sensor goes where is really quite model-specific.

What I did was to write down the values in the PC Health area of bios and compared them with values from sensors.
in0: corresponded to Vcore, Temp2 is the CPU temp, Temp1 does not seem connected, and System fan does not seem connected.
That was all I could match up. Does anyone know how to cause changes in CPU Temp or of fan.

Running any CPU-intensive program ought to make your CPU hotter.

That is expected of course. What was not obvious to me was a program which comes with Slack 13.37 called gkrellm. As I dig into this the use of "sensors" becomes less relevant.

Both have different uses, gkrellm doesn't make sensors useless.

sensors is far more useful for debugging lm_sensors if you have a problem with it. It can also be used in automatic scripts, even on something standalone.

gkrellm is a graphical application with all the strengths and problems that implies.