Bug 6051

Created attachment 7288 [details]
acpidump

Created attachment 7289 [details]
dmesg output

Created attachment 7290 [details]
dmidecode output

Created attachment 7291 [details]
/proc/interrupts

Created attachment 7292 [details]
lspci -vv

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.

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.

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...

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.

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.

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. 
 

Which DSDT file do you mean?

Which DSDT file do you mean?

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.

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.

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...

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.

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.

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.

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.

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.

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.

whups

i mean konstantin, not ivor, sorry :-)

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.

Created attachment 8204 [details]
Modified Novell DSDT

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.

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.

I am trying to get SuSE 10.1 running on an Fujitsu Siemens - Amilo Pro
V2030(20). Martin J

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.

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.

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...