Mailinglist Archive: opensuse-amd64 (40 mails)

< Previous Next >
Re: [suse-amd64] ACPI.
  • From: Pierre Patino <ppatino@xxxxxxxxxxxxx>
  • Date: Tue, 24 Oct 2006 21:40:04 -0700
  • Message-id: <453EEAA4.7030905@xxxxxxxxxxxxx>
Walter Kerkhofs wrote:
Op woensdag 18 oktober 2006 01:33, schreef Joe Morris (NTM):
Walter Kerkhofs wrote:
Op dinsdag 17 oktober 2006 06:41, schreef Pierre Patino:
When shutting down the computer I always saw a warning in red about
acpid, so i decided to do something about it.
lm sensors has nothing to do with acpid.

Ok, this I did not know.

Where must I put the generated lines in ?
If you are using the package from SuSE, it says when you set it up.

And where do I have to put these lines:

#I2C adapter drivers
modprobe i2c-viapro
modprobe i2c-isa
#I2C chip drivers
modprobe eeprom
#Warning the required module smbus-arp is not currently installed on
your system. #For status of 2.6 kernel ports see
htpp://secure.netroedge.com/~Im78/supported.html #If driver is built-in
to the kernel, or unavailable, comment out the following line. modprobe
smbus-arp
modprobe w83627hf
#sleep 2 # optional
/usr/bin/sensors -s # recommended
This looks like the init.d script, but not completely. Check
/usr/share/doc/packages/sensors/prog/init/lm_sensors.init.suse and copy
it to /etc/init.d and rename to lm_sensors. The sensors-detect script
should create automatically /etc/sysconfig/lm_sensors with the list of
modules you will be loading.

As soon that I have a little more time I will look it up.

But before putting the other lines in place I ran:

/usr/bin/sensors -c /etc/sensors.conf

and got this as a result:

w83697hf-isa-0290
Adapter: ISA adapter
VCore: +1.54 V (min = +1.71 V, max = +1.89 V) ALARM
+3.3 V: +3.28 V (min = +3.14 V, max = +3.47 V) ALARM
+5V: +5.08 V (min = +4.76, max = +5.24 V) ALARM
+12V: +11.13 V (min = +10.82 V, max = +13.19V) ALARM
-12V: +0.55 V (min = -13.18 V, max = -10.80 V) ALARM
-5V: +5.10 V (min = -5.25 V, max = -4.75 V) ALARM
V5SB: +5.46 V (min = +4.76 V, max = +5.24 V) ALARM
VBat: +0.51 V (min = +2.40 V, max = +3.60 V) ALARM
fan1: 0 RPM (min = 417 RPM, div = 32) ALARM
fan2: 3183 RPM (min = 17763 RPM, div = 2) ALARM
These mean you need to tweak /etc/sensors.conf for your chips (every
motherboard may need this).

This also I have to invastigate more, because I do not know wich chip I have.
And in this file they only mention the chip instaed of the type of motherboard, so I have to find out the chip I have.

temp1: +32° C (high = +34°C, hyst = +76°C) sensor =
thermistor

temp2: +29.5°C (high = +80°C, hyst = +75°C) sensor =
thermistor

alarms: chasis intrusion detection ALARM beep_enable: Sound alarm disabled
Chassis intrusion is a feature on your motherboard, not because you
opened the case. It is probably disabled.

The alarm about the chasis intrusion detection that I can understand,
because I have opened the chasis once.

But the rest I do not know ?
Read some of the documentation. You will need to tweak the settings in
/etc/sensors.conf to make the output relevant for your motherboard.

Does anyone know what is wrong ?
It needs configuration, like most programs. But TBO, this will only get
your sensors program going, it will have no effect on your acpid problem.

Man acpid says that acpid reads the data in /proc/acpi/events, but when I put my pointer over that file in Konqueror the summary says that it is emtpy.
When I do the same with the file dsdt it also says it is emtpy, every directory or file under /proc/acpi is empty.

Has this somting to do with dose lines I still have to insert ?

Thanks in advance.

Walter Kerkhofs

Files in /proc/whatever are not exactly regular files. You have to do a "cat" on the file such that the kernel gets a message to actually gather data and pump it to you.


For example: As root:

cd /proc/acpi/
ls -la
-r-------- 1 root root 0 Oct 24 19:32 event
dr-xr-xr-x 10 root root 0 Oct 24 19:32 .
-rw-r--r-- 1 root root 0 Oct 24 21:32 wakeup
dr-xr-xr-x 2 root root 0 Oct 24 21:32 thermal_zone
-rw-r--r-- 1 root root 0 Oct 24 21:32 sleep
dr-xr-xr-x 3 root root 0 Oct 24 21:32 processor
dr-xr-xr-x 2 root root 0 Oct 24 21:32 power_resource
-r--r--r-- 1 root root 0 Oct 24 21:32 info
dr-xr-xr-x 2 root root 0 Oct 24 21:32 fan
-r-------- 1 root root 0 Oct 24 21:32 fadt
dr-xr-xr-x 2 root root 0 Oct 24 21:32 embedded_controller
-r-------- 1 root root 0 Oct 24 21:32 dsdt
dr-xr-xr-x 3 root root 0 Oct 24 21:32 button
dr-xr-xr-x 2 root root 0 Oct 24 21:32 battery
-rw-r--r-- 1 root root 0 Oct 24 21:32 alarm
dr-xr-xr-x 2 root root 0 Oct 24 21:32 ac_adapter

cat alarm
2006-10-00 01:50:**

cat info
version: 20050408

cat processor/CPU0
active state: C1
max_cstate: C8
bus master activity: 00000000
states:
*C1: type[C1] promotion[--] demotion[--] latency[000] usage[02459213]


Notice how all files are "empty" yet the cat command (which executes open() and read() system calls) gets data from the "files".
The /proc directory is special. It is a hook into the kernel among other things.

I've never pointed a browser into these files and would avoid doing so to minimise confusion.








< Previous Next >
Follow Ups