# zcat /proc/config.gz | grep ACPI
# Power management options (ACPI, APM)
# ACPI (Advanced Configuration and Power Interface) Support
CONFIG_ACPI=y
CONFIG_ACPI_SLEEP=y
CONFIG_ACPI_SLEEP_PROC_FS=y
# CONFIG_ACPI_SLEEP_PROC_SLEEP is not set
CONFIG_ACPI_PROCFS=y
CONFIG_ACPI_AC=m
CONFIG_ACPI_BATTERY=m
CONFIG_ACPI_BUTTON=m
CONFIG_ACPI_FAN=m
# CONFIG_ACPI_DOCK is not set
CONFIG_ACPI_PROCESSOR=m
CONFIG_ACPI_THERMAL=m
# CONFIG_ACPI_ASUS is not set
# CONFIG_ACPI_TOSHIBA is not set
CONFIG_ACPI_BLACKLIST_YEAR=0
CONFIG_ACPI_DEBUG=y
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_SYSTEM=y
# CONFIG_ACPI_CONTAINER is not set
# CONFIG_ACPI_SBS is not set
CONFIG_X86_ACPI_CPUFREQ=m
# CONFIG_X86_ACPI_CPUFREQ_PROC_INTF is not set
CONFIG_PNPACPI=y
# CONFIG_THINKPAD_ACPI is not set
CONFIG_ATA_ACPI=y

Created attachment 12288 [details]
acpidump output

Created attachment 12289 [details]
dmidecode output

>cat 3 > /proc/acpi/fan/FAN/state does nothing
I think you probably mean "echo 3 >/proc/acpi/fan/FAN/state"
please attach the dmesg output.
try:
echo 0xffffffff >/sys/module/acpi/parameters/debug_level
echo 3 >/proc/acpi/fan/FAN/state
echo 0x0f >/sys/module/acpi/parameters/debug_level
and attach the dmesg output as well.

(In reply to comment #4)
> >cat 3 > /proc/acpi/fan/FAN/state does nothing
> I think you probably mean "echo 3 >/proc/acpi/fan/FAN/state"
> please attach the dmesg output.
> try:
> echo 0xffffffff >/sys/module/acpi/parameters/debug_level
> echo 3 >/proc/acpi/fan/FAN/state
> echo 0x0f >/sys/module/acpi/parameters/debug_level
> and attach the dmesg output as well.
> 

About /proc/acpi/fan/FAN/state - it was a typo, thanks.

I'll attach dmesg output with debug enabled now.

Created attachment 12303 [details]
dmesg output

dmesg > dmesg.out after
echo 0xffffffff >/sys/module/acpi/parameters/debug_level
echo 3 >/proc/acpi/fan/FAN/state
echo 0x0f >/sys/module/acpi/parameters/debug_level

The bug is still has "NEEDINFO" status. Should I provide some additional info?

Created attachment 12564 [details]
new DSDT to override the original one

Hi, Andrey,
Sorry for the delay.
Could you please override the old dsdt and do the same test.

Created attachment 12644 [details]
dmesg output with new DSDT

If I did everything right with DSDT and kernel, this is the new dmesg output after running

#!/bin/sh
echo 0xffffffff >/sys/module/acpi/parameters/debug_level
echo 3 >/proc/acpi/fan/FAN/state
echo 0x0f >/sys/module/acpi/parameters/debug_level

Is the fan actually turned off now?
can you hear the fan spin on when you "echo 0 > /proc/acpi/fan/FAN/state"?

When I boot into a kernel with a new DSDT:
# cat /proc/acpi/fan/FAN/state
status:                  off

but the fan is still running.

However I found a strange thing: if laptop is resumed from suspend-to-ram the fan is off. I mean really off. If it is importaing, I can attach a dmesg log after resuming. 

Created attachment 12667 [details]
debug patch

Interesting.
Then can you turn on the fan after S3? and turn off again?
I guess the fan will also be turned off without overriding the DSDT, can you verify this?
Please apply this debug patch and try to turn on&off the fan and attach the dmesg output as well as the dmesg after S3.

New info:

1) Without new DSDT 2.6.23-rc5 with debug patch
- cooler is always on
- cooler is on after resuming from S3
- 'cat /proc/acpi/fan/FAN/state' always say 'status: on'
- 'echo 3 > /proc/acpi/fan/FAN/state' does nothing
- 'echo 0 > /proc/acpi/fan/FAN/state' does nothing

2) With new DSDT 2.6.23-rc5 with debug patch
- cooler is always on
- laptop doesn't go to S3 (IMHO the reason is debug patch)
- 'cat /proc/acpi/fan/FAN/state' always say 'status: off'
- 'echo 3 > /proc/acpi/fan/FAN/state' does nothing
- 'echo 0 > /proc/acpi/fan/FAN/state' makes really much noise is system log. The messages doesn't stop at all. The fan is still running, the 'echo' command doesn't exit properly.

3) With new DSDT 2.6.23-rc5 without debug patch
- cooler is on after boot
- after resuming from S3 cooler is off
- 'cat /proc/acpi/fan/FAN/state' always say 'status: off'
- 'echo 3 > /proc/acpi/fan/FAN/state' does nothing
- 'echo 0 > /proc/acpi/fan/FAN/state' stops the cooler. The output of the command is 
"echo: write error: Exec format error" 
Next time when I execute this command, cooler starts for a second and then stops again. If I try to execute this command after 
'echo 0xffffffff >/sys/module/acpi/parameters/debug_level',
I also get infinite number of messages in syslog, and the 'echo' command doesn't exit properly. The way to finish 'echo' execution and to stop getting syslog messages is 
'echo 0x0f >/sys/module/acpi/parameters/debug_level'.

However in this case the fan is not always off. After some time of idle it starts again for a few seconds and then stops. I analized this behavior for a while with
'watch -n 1 cat /proc/acpi/thermal_zone/THRM/*'
and I guess that fan starts when CPU temp is more than 50C and then stops when the temp is under 50C. Seems almost ok, but in my mind it would be more effective to lower the temp to 45C for example and only then stop the fan. 


I will attach dmesg logs now.

Created attachment 12668 [details]
dmesg output after resuming from 2.6.23-rc5 kernel with debug patch and with old DSDT

Created attachment 12669 [details]
dmesg from 2.6.23-rc5 with debug patch and with old DSDT

Created attachment 12670 [details]
dmesg from 2.6.23-rc5 with debug patch with new DSDT

After echo 0 > /proc/acpi/fan/FAN/state
It's just a part of all messages.

So with new DSDT I'm almost happy after echo 0 > /proc/acpi/fan/FAN/state.

But as I already said it would be better for me if the temp when fan turns on will be higher and the temp when it turns off will be lower. For example 65C and 45C. Because for now fan starts spinning too often.

And the fan status appears to be incorrect, when the temp is more than 50C, the fan starts spinning but /proc/acpi/fan/FAN/state gives incorrect state "off".

The fact that I really cannot control fan with /proc/acpi/fan/FAN/state is sad too. Once it is turned "off" with echo 0 > /proc/acpi/fan/FAN/state I cannot get it running again, it only starts when CPU temp reaches the threshold.

Sorry for impatience, are there any news?

I can confirm this bug. I have the same chipset on my notebook (Fujitsu Siemens AMILO Pro v2055), and I cannot change the fan speed. My CPU needs continous cooling (Celeron M 420), so when I get back from hibernate-ram, the cooler starts spinning for a second and then stops completely. This is a very big problem, because my CPU overheats very quickly without any cooling, so I cannot use the hibernate-ram mode.

I can gladly help you with any info. I'm looking forward for the solution.

Hi, Andrey,
Sorry for the delay, can you please try:
1.echo 0xffff0000 >/sys/module/acpi/parameters/debug_layer
  echo 0x1f >/sys/module/acpi/parameters/debug_level 
2.dmesg -c
3.trun on/off the fan by "echo 0 or 3 > /proc/acpi/fan/FAN/state"
and attach the dmesg output please?

Please do this test with the new DSDT and without the debug patch.

Created attachment 13103 [details]
Console output with dmesg

I've executed commands that you have said and saved their output to text file.

Created attachment 13105 [details]
override the old dsdt

It seems that the power resource device PFAN always return the invalid state.
Please try the new DSDT attached, and do the same test as in comment #20.

Created attachment 13106 [details]
Console output with new DSDT

Now 'echo' command doesn't give an error, but once I've turned my fan off, I can't force it to start again. However this behavior is much better than default.

Well, I'm not sure if we are in the right direction.:(

First, your original DSDT shows that FAN device has empty _PS0, _PS3 method,
usually this means that the fan is controlled by BIOS.
I found that power resource device PFAN is not referenced by any device, and it may be used for fan power control, so I did some hack in your DSDT.
And the test results show that PFAN can be used to control FAN state.
This is a good news, but we still have one problem.
Here is the _STA method of power resource file PFAN.
                    Method (_STA, 0, NotSerialized)
                    {
                        And (\_SB.PCI0.PIB.PMRD (0xFF), 0x04, Local7)
                        ShiftRight (Local7, 0x01, Local7)
                        Return (Local7)
                    }
_STA should return 0/1 according to the ACPI spec, where "0" means power resource is off and "1" means power resource is on.
We can see that the _STA method in your DSDT always return 0 or 2. thus we are always told that power resouce/fan is off because the bit 0 of _STA return value is always 0. So this is apparentlly a BIOS bug.
The problem is that we don't know which bit of \_SB.PCI0.PIB.PMRD(0xFF) stands for the status of power resource PFAN. I tried to change ShiftRight (Local7, 0x01, Local7) to ShiftRight (Local7, 0x02, Local7) in comment #22 but without any luck.
Now we need to find out which bit stands for PFAN status. But all these efforts only make sense only if the mother board vendor really wants PFAN to
control fan device.
But one thing strange is that you said "MS Windows slows down the fan when CPU is cool and speeds it up when CPU is busy."
Now this is also true for Linux after overriding the DSDT except that it starts spinning too often, right?  :)
Maybe you can override the active trip point by adding a boot parameter thermal.act=xxx, here xxx is the temperature you want the fan starts to spin.

BTW: for the wrong buggy _STA issue: this only confuses the user who want to get the fan state. but let's debug further to see if we can make ACPI work perfectly on this machine. :)

Created attachment 13122 [details]
DSDT-3

new DSDT to override.
the new _STA mathod can help us to find out which bit stands for the PFAN status.
                    Method (_STA, 0, NotSerialized)
                    {
                        Return (\_SB.PCI0.PIB.PMRD(0xFF))
                    }
I think you need to do the following test:
1.don't override the active trip point.
2.echo 0xffff0000 >/sys/module/acpi/parameters/debug_layer
  echo 0x1f >/sys/module/acpi/parameters/debug_level 
3.dmesg -c
4.cat /proc/acpi/power_resource/PFAN/state for several times
5.if the fan is off, echo 0 > /proc/acpi/fan/FAN/state
6.cat /proc/acpi/power_resource/PFAN/state once you hear the fan state changes.
The main idea is that PFAN is actually on when fan is on and PFAN is off
when fan is off.
we can get the value of \_SB.PCI0.PIB.PMRD(0xFF)) and compared it with the
actually fan state so that we can find out which bit stands for the PFAN state.

Created attachment 13136 [details]
Console output with DSDT-3

Thank you for your time and for complete problem explanation. I'll try to deal with trip points a little bit later. I wanted to change their values when I just posted the bug report, but the /proc entries were already made read-only (by some of changes in kernel ACPI system) and the kernel options didn't exist yet.

Here's console output from kernel with DSDT-3

BTW, as I already said, this laptop is based on FIC LM7W platform. FIC itself didn't made an end-product on this platform, but Roverbook, Everex and some other small verdors did. I thinks that BIOS was not made by Rover and it is developed by FIC, so this bug probably exists in other similar laptops.

Oops, it seems that we still need a step 7 to get the dmesg output after step 6 is finished in comment #25. :(

Created attachment 13167 [details]
Console output with DSDT-3 and dmesg as 7th step

On the 5th step the fan was on. After that step it turned off.

Created attachment 13195 [details]
patch-debug-power-state

can you apply this debug patch and see if you can turn on/off the fan correctly?

System just booted, the fan is on.

laptop rikz # cat /proc/acpi/fan/FAN/state
status:                  off
laptop rikz # echo 3 > /proc/acpi/fan/FAN/state
/* the fan is still on */
laptop rikz # cat /proc/acpi/fan/FAN/state
status:                  off
laptop rikz # echo 0 > /proc/acpi/fan/FAN/state
/* fan actually stops after executing this command */
laptop rikz # cat /proc/acpi/fan/FAN/state
status:                  on
laptop rikz # echo 3 > /proc/acpi/fan/FAN/state
/* fan is still stopped */
laptop rikz # cat /proc/acpi/fan/FAN/state
status:                  off

now when CPU temperature reaches 55C the fan starts automatically, but its state in /proc/acpi doesn't change.

I can force fan to start by executing
echo 0 > /proc/acpi/fan/FAN/state
it runs for a while and then stops. I can force it to start again by executing
echo 3 > /proc/acpi/fan/FAN/state
echo 0 > /proc/acpi/fan/FAN/state

When the fan is turned on and the CPU temp is low, I can force it to stop by executing
echo 3 > /proc/acpi/fan/FAN/state

Sorry for such a big message but I don't really know which cases should I mention.

Created attachment 13885 [details]
patch-debug-power-state

Please try this patch with DSDT-3
Please set the correct value to /sys/module/acpi/power/parameters/actual_power_state,
set 1 when fan is on and 0 when fan is off.
And then please attach the dmesg after the same test.

Hi, Andrey,
Any test result of comment #31?
I'll close this bug if no response from you. :)

Close this bug as no reponse from the bug reporter.

I'm very-very sorry for a huge delay.

Just patched 2.6.24 with the latest debug patch, buy I see no /sys/module/acpi/power/parameters/actual_power_state:

# ls /sys/module/acpi/
parameters


here's a part of kernel config
# cat .config|grep ACPI
CONFIG_ACPI=y
CONFIG_ACPI_SLEEP=y
CONFIG_ACPI_PROCFS=y
CONFIG_ACPI_PROCFS_POWER=y
CONFIG_ACPI_SYSFS_POWER=y
CONFIG_ACPI_PROC_EVENT=y
CONFIG_ACPI_AC=m
CONFIG_ACPI_BATTERY=m
CONFIG_ACPI_BUTTON=m
CONFIG_ACPI_FAN=m
# CONFIG_ACPI_DOCK is not set
CONFIG_ACPI_PROCESSOR=m
CONFIG_ACPI_THERMAL=m
# CONFIG_ACPI_ASUS is not set
# CONFIG_ACPI_TOSHIBA is not set
CONFIG_ACPI_CUSTOM_DSDT=y
CONFIG_ACPI_CUSTOM_DSDT_FILE="/root/DSDT-3.hex"
CONFIG_ACPI_BLACKLIST_YEAR=0
CONFIG_ACPI_DEBUG=y
# CONFIG_ACPI_DEBUG_FUNC_TRACE is not set
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_SYSTEM=y
# CONFIG_ACPI_CONTAINER is not set
# CONFIG_ACPI_SBS is not set
CONFIG_X86_ACPI_CPUFREQ=m
# CONFIG_X86_ACPI_CPUFREQ_PROC_INTF is not set
CONFIG_PNPACPI=y
# CONFIG_THINKPAD_ACPI is not set
CONFIG_ATA_ACPI=y
# CONFIG_PATA_ACPI is not set

should I change something?



Without the patch but with DSDT-3 I almost succeeded with the same tests:

1) just started the system.
/proc/acpi/fan/FAN/state reports status "off", but the fan is actually turned on and runs at full speed. Incorrect.
2) echo 0 > /proc/acpi/fan/FAN/state 
/proc/acpi/fan/FAN/state reports status "on", the fan is still running but the speed is decreased.
3) echo 3 > /proc/acpi/fan/FAN/state
/proc/acpi/fan/FAN/state reports status "off", and the fan is really turned off

Here we go, after this actions the /proc/acpi/fan/FAN/state is now reporting correct values for fan state:

4) Now I raised the CPU temp >55C 
/proc/acpi/fan/FAN/state reports status "on", fan is running at half speed (it started automatically) 
5) When the temp dropped below 50C threshold
/proc/acpi/fan/FAN/state reports status "off", fan is really turned off

6) When the CPU temp is below 50C I can force fan to start with
echo 0 > /proc/acpi/fan/FAN/state
and /proc/acpi/fan/FAN/state reports the correct state "on" then too. But soon the fan turns of automatically. When it is turned off, the state is correct again, it is "off".

So now the initial fan state returned by /proc/acpi/fan/FAN/state after booting the system is still incorrect. But after running "echo" command twice, the state is fixed, now fan is started/stopped automatically and /proc/acpi/fan/FAN/state returns actual info.
And I'm quiet sure that the initial fan speed is higher than the speed when fan is turned automatically, if it makes any sense.

Hi, Andrey,
This is a BIOS problem more than a Linux/ACPI problem.
All the thing that we tried, like overriding DSDT, applying debug patches, are just workarounds that will never have a chance to be merged in mainline kernel. 
Sorry that I don't have time to work on this bug which is apparent a BIOS problem. And as it's not a Linux kernel bug, I'll closed this bug and mark it as INVALID. Is it okay with you?

I'm okay with that. 

Anyway, thanks for the help, Zhang, I really appreciate it.