lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 6 Nov 2008 01:35:44 +0100
From:	Tino Keitel <tino.keitel@...ei.de>
To:	ibm-acpi-devel@...ts.sourceforge.net, linux-kernel@...r.kernel.org
Subject: Re: [ibm-acpi-devel] Fan level 7 after resume wit 2.6.28-rc3

On Wed, Nov 05, 2008 at 14:24:01 -0200, Henrique de Moraes Holschuh wrote:

[...]

> It should not have set the fan to level 7, so it means we will need to add
> debugging hints to the driver.  I don't have my T43 with me right now, or I
> could try to reproduce the issue.
> 
> Are you confortable with adding some printk's to kernel source?  If so, try
> to printk the interesting bits in fan_suspend and fan_resume on
> drivers/misc/thinkpad_acpi.c.

In fan_init(), fan_control_desired_level is set to 7, and never changed
to anything else. It is not set in fan_suspend() because
tp_features.fan_ctrl_status_undef is 0 (also set in fan_init()).

In fan_resume(), saved_fan_level is taken from
fan_control_desired_level. current_level is read and set to
TP_EC_FAN_AUTO.

Now the following check is true:

saved_fan_level == 7 && !(current_level & TP_EC_FAN_FULLSPEED))

So do_set is set to true and the fan speed is set to 7 at resume.

I tried to write a correct patch, but I got lost in all that
fan_control_desired_level, fan_control_initial_status and
tp_features.fan_ctrl_status_undef stuff.

My brain says that one would just read the current fan settings from
the EC at initialization. Then, after resume, this setting is restored
unconditionally, or at least if it differs from current_level. The
attached patch works for me. However, I don't have all the knowledge
about older models and their specific behaviour.

Correction: I just tested a bit further, and it doesn't work. If I set
fan level to 3, suspend, resume, set fan level to auto, and
resume/suspend again, fan level is restored to 3. This is because
fan_control_desired_level isn't updated by fan_update_desired_level()
if it is set back to auto, but kept at the old value. So, my impression
is that all the values and states should be cleaned up a bit and
simplified. In the current state, there are a lot of strage checks and
quirks that have side effects when other parts are changed.

Regards,
Tino

View attachment "thinkpad-acpi_fan-level-restore-fix.diff" of type "text/x-diff" (860 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ