Bug 6051 - no fan control - Fujitsu-Siemens AMILO Pro V2030
Summary: no fan control - Fujitsu-Siemens AMILO Pro V2030
Status: REJECTED INVALID
Alias: None
Product: ACPI
Classification: Unclassified
Component: Power-Fan (show other bugs)
Hardware: i386 Linux
: P2 normal
Assignee: Konstantin Karasyov
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-02-10 07:42 UTC by Martin Jürgens
Modified: 2007-01-22 20:51 UTC (History)
6 users (show)

See Also:
Kernel Version: 2.6.15
Subsystem:
Regression: ---
Bisected commit-id:


Attachments
acpidump (79.19 KB, text/plain)
2006-02-10 07:44 UTC, Martin Jürgens
Details
dmesg output (15.28 KB, text/plain)
2006-02-10 07:50 UTC, Martin Jürgens
Details
dmidecode output (9.07 KB, text/plain)
2006-02-10 07:54 UTC, Martin Jürgens
Details
/proc/interrupts (612 bytes, text/plain)
2006-02-10 07:56 UTC, Martin Jürgens
Details
lspci -vv (11.54 KB, text/plain)
2006-02-10 07:57 UTC, Martin Jürgens
Details
DSDT debug patch (621 bytes, patch)
2006-02-22 09:23 UTC, Konstantin Karasyov
Details | Diff
assign power resource to fan device (636 bytes, patch)
2006-02-22 09:33 UTC, Konstantin Karasyov
Details | Diff
patched DSDT.aml file (14.60 KB, patch)
2006-03-01 16:23 UTC, Konstantin Karasyov
Details | Diff
absolute path for PFAN is used (14.60 KB, text/plain)
2006-03-09 08:09 UTC, Konstantin Karasyov
Details
Updated DSDT (14.60 KB, application/octet-stream)
2006-05-25 07:36 UTC, Konstantin Karasyov
Details
Modified Novell DSDT (14.55 KB, application/octet-stream)
2006-05-25 07:38 UTC, Konstantin Karasyov
Details

Description Martin Jürgens 2006-02-10 07:42:49 UTC
Most recent kernel where this bug did not occur:
Distribution: Ubuntu Dapper Drake, opensuse 10.0, 10.1, Fedora Core 4, Knoppix,
Gentoo (with 2.6.15.1 vanilla kernel (built via genkernel))
Hardware Environment: Fujitsu-Siemens AMILO Pro V2030
Software Environment:
Problem Description: Fan spins at full power. It is not possible to change this
via echo -n x > /proc/acpi/fan/FAN/state
values in /proc/acpi/thermal_zone/THRM seem to be ok.

Steps to reproduce:
Comment 1 Martin Jürgens 2006-02-10 07:44:55 UTC
Created attachment 7288 [details]
acpidump
Comment 2 Martin Jürgens 2006-02-10 07:50:51 UTC
Created attachment 7289 [details]
dmesg output
Comment 3 Martin Jürgens 2006-02-10 07:54:34 UTC
Created attachment 7290 [details]
dmidecode output
Comment 4 Martin Jürgens 2006-02-10 07:56:01 UTC
Created attachment 7291 [details]
/proc/interrupts
Comment 5 Martin Jürgens 2006-02-10 07:57:31 UTC
Created attachment 7292 [details]
lspci -vv
Comment 6 Martin Jürgens 2006-02-10 08:06:21 UTC
I forgot one thing: In some distributions like opensuse I can boot with
pci=noacpi. Then it is possible to suspend-to-disk, after switching my laptop on
again fan control works like a charm.
Comment 7 Kristoffer Lund 2006-02-18 09:30:02 UTC
I have the same problem with a Fujitsi Siemens Amilo M3438G. Can not suspend to
try if it starts then, though. I don't know much about these issues, so please
request additional data (and how to create it) and I'll be happy to attach
anything that may help. =)

I am running Ubuntu Dapper with the 2.6.25 kernel.
Comment 8 Konstantin Karasyov 2006-02-22 09:23:58 UTC
Created attachment 7437 [details]
DSDT debug patch

Ok, the fan device assigned as cooling device for active cooling in your system
has no control methods and will always return 0 (on) state. But there is SFAN
method defined, which looks like fan control.

Here is the DSDT debug patch. It adds debug messages on SFAN method execution,
and the fan state changes.

Could you apply this patch and force the suspend, to see if this SFAN method is
the reason of fan activities.

Please, don't hesitate to ask, if you have any questions, need assistance,
etc...
Comment 9 Konstantin Karasyov 2006-02-22 09:33:26 UTC
Created attachment 7438 [details]
assign power resource to fan device

Here is another DSDT patch, which tries to assign power resource PFAN to FAN
device.

It is untested, so it would be safer to have the separate kernel to try it out.
Comment 10 Martin Jürgens 2006-02-22 11:36:13 UTC
I will report the results at the weekend. Yesterday a suse developer attached a
patched dsdt file in the Novell bugtracker which you may want to have a look at:
https://bugzilla.novell.com/show_bug.cgi?id=141970

I will try the things mentioned in the Novell bugtracker at the weekend, too.
Comment 11 Konstantin Karasyov 2006-02-26 08:10:51 UTC
Martin,  
With the modified DSDT do the /proc/acpi/fan/*/state file shows the correct fan  
state after suspend, i.e. 'on' when fan is spinning, 'off' - when it's not?  
  
Kristoffer, 
Please check bug #5670. 
 
Comment 12 Martin Jürgens 2006-02-26 08:45:16 UTC
Which DSDT file do you mean?
Comment 13 Martin Jürgens 2006-02-26 08:52:34 UTC
Which DSDT file do you mean?
Comment 14 Konstantin Karasyov 2006-02-28 05:46:18 UTC
I mean fixed DSDT from Novell bug tracker. The fan device defined there has 
_PSC method, which always returns 0 (i.e. device is 'on'). This could be the 
reason of the fan misbehavior.

Also, did you had a chance to try the latest patch i've submitted - it 
assignes power resource PFAN to fan device instead of using power state 
methods, so the fan state is evaluated from _STA method rather than from _PSC.
Comment 15 Martin Jürgens 2006-02-28 07:01:50 UTC
The state does not change when the fan is off when I use the dsdt file from the
novell bugtracker after or before a suspend to disk.

I can't patch my dsdt file with your patch so assistance in patching the dsdt
file would be great.
Comment 16 Konstantin Karasyov 2006-03-01 16:23:08 UTC
Created attachment 7492 [details]
patched DSDT.aml file

Martin,
Here is the patched DSDT.aml file for Fujitsu-Siemens AMILO Pro V2030. To use
this file you should do the following (the operations are the same as with the
Novell DSDT file):
- copy the attached file to:
  /etc/DSDT.aml
- set the variable ACPI_DSDT="/etc/DSDT.aml"
  in /etc/sysconfig/kernel
- call mkinitrd
- reboot

The instructions are available from here:
https://bugzilla.novell.com/show_bug.cgi?id=141970

Ubnfortunately, I don't have the same system to try this patch myself, so,
please, don't hesitate to contact me if you'll experience the problems, have
questions, etc...
Comment 17 Martin Jürgens 2006-03-02 06:52:11 UTC
Thanks for your help. The attached DSDT file does not work, the kernel crashes
at booting time (BUG: soft lockup detected on CPU#0!".
Pid: 5,comm:		khelper
EIP: 0060:[<c011c5fd>] CPU: 0
EIP is at __do_softirq+0x2c/0x7f

If you need the full output just leave a note here, I will make a photo then.
Comment 18 Konstantin Karasyov 2006-03-09 08:09:57 UTC
Created attachment 7545 [details]
absolute path for PFAN is used

Martin,

Here is the previous patch, but the power resource for fan device is defined
with an absolute path to it. This may help.

And again, it is safer to have a separate kernel (with a separate boot entry)
for debugging/testing purposes.
Comment 19 Martin Jürgens 2006-03-22 11:32:18 UTC
Sorry.. My internet does not work correctly and I do not have a lot of time
right now.

When I have time again, I will give you the results.
Comment 20 Martin Jürgens 2006-04-20 16:34:04 UTC
So far, I tried the latest patch but I didn't have any success. The fan still
spins and echoing does not get the lights on.

A very mysteric thing is this:

My system does not boot when I use the DSDT patch with opensuse 10.1 and the
bootopts splash=silent showopts . When I remove them, my system boots fine but
the fan spins and echoing does not stop it from spinning.

When I remove them and boot with pci=noacpi my system hangs at booting time.
Comment 21 Martin Jürgens 2006-04-20 16:56:02 UTC
I just noted that I cannot hibernate anymore in opensuses rc, when I boot with
pci=noacpi which is required for me to hibernate opensuse and other
distributions the system does not start. In other distributions, the kernel does
not start, too when booting with pci=noacpi.
Comment 22 Martin Jürgens 2006-05-09 10:45:31 UTC
ivor, if you want i can give you ssh access to my laptop and tell "fan spins" ;
"fan does not spin" etc. I think that this would be much easier.

Just tell me which distribution you want to have and I will make a fresh install.
Comment 23 Martin Jürgens 2006-05-09 10:46:19 UTC
whups

i mean konstantin, not ivor, sorry :-)
Comment 24 Konstantin Karasyov 2006-05-25 07:36:58 UTC
Created attachment 8203 [details]
Updated DSDT

Martin,

Here are 2 modified DSDTs.
The first one is another try to make PFAN work as power resource for fan
device.
The second is slightly modified DSDT from Novell bugzilla to made fan change
its state.
Comment 25 Konstantin Karasyov 2006-05-25 07:38:28 UTC
Created attachment 8204 [details]
Modified Novell DSDT
Comment 26 Martin Jürgens 2006-05-25 08:09:30 UTC
Konstantin, thanks for your reply.

here is what happens with the first file:

state says "off" although the fan spins, but when i echo -n 0 > state, it says
"exec format error" and it does not spin anymore after a few seconds. state
stays "off" then. After some time it starts to spin again and state stays "off".
It does not stop spinning. When I echo -n 0 > state again I do not get "exec
format error" but it stops spinning after a few seconds but this only works
sometimes.

If you have any questions, please ask. I will now try the modified Novell patch.
Comment 27 Martin Jürgens 2006-05-25 08:16:30 UTC
When using the second dsdt file, the fan spins and state is "on". When I echo 3
to state the fan does not spin and state says "off".

After some time it starts spinning again. State stays "off". But the fan stops
spinning again when the notebook is cool again.
Comment 28 Roman Krais 2006-07-29 07:43:20 UTC
I am trying to get SuSE 10.1 running on an Fujitsu Siemens - Amilo Pro
V2030(20). Martin J
Comment 29 Roman Krais 2006-08-05 10:24:38 UTC
Another issue with the fan which might be related. I don't understand why the
fan is running (with about 50% of its power), even though the computer is idle:

# cat /proc/acpi/thermal_zone/THRM/trip_points
critical (S5):           110 C
passive:                 78 C: tc1=3 tc2=1 tsp=80 devices=0xcbeaefc0
active[0]:               60 C: devices=0xcbe98700

# cat /proc/acpi/thermal_zone/THRM/temperature
temperature:             49 C

# cat cooling_mode
cooling mode:   passive

The fan starts when the temperature reaches 55 degree and turns off when the
temperature is going below 49 degree. I expected that the fan to turn on only at
60 degree and wonder if it is a configuration or a DSDT/kernel problem

I am using a Amilo Pro V2030I with patched DSDT.aml from 
https://bugzilla.novell.com/show_bug.cgi?id=141970.
# echo -n 3 > /proc/acpi/fan/FAN/state 
enables the fan control on my SuSE 10.1 system.
Comment 30 Konstantin Karasyov 2006-09-11 08:37:29 UTC
Basically, the problem is that the object 'FAN' which the cooling device for 
thermal zone THRM (assigned in _AL0) doesn't have any methods for actual fan 
control. These methods could be defined through power resources or power state 
methods. Each power resource has '_ON', '_OFF' and '_STA' methods to power 
on/off device and to get its current power state.
DSDT already has functional power resource (PFAN) for fan device, so I tried to 
assign it to the device 'FAN', but with no success.
Modified DSDT from Novell implements fan control through power state methods, 
invoking PFAN._ON method in FAN._PS0 and PFAN._OFF method in FAN._PS3. But in 
this case power state of the fan is evaluated from _PSC object, which is always 
0 (i.e. 'on'). In my modification of Novell DSDT I tried to set _PSC object to 
correct values (to 0 when turning the fan on, to 3 - when off), but '_ON' 
and '_OFF' methods defined in PFAN uses SFAN method, which actually switches 
the fan device. This method (SFAN) is invoked from several places (besides PFAN 
_ON/_OFF methods), so the fan state (_PSC) remains unchanged during such 
switches.

The problem should be resolved by defining power resource PFAN in FAN device, 
but somehow it failed on this system.
Comment 31 Konstantin Karasyov 2007-01-22 20:50:18 UTC
With all my respect - this is the BIOS bug, so no ACPI functionality is 
involved here, and it's obvious that there are no patches will be submittted, 
at least ones, that turn the issue under the kernel scope.
For more info look at the comments above...

Note You need to log in before you can comment on or make changes to this bug.