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:	Wed, 03 Jun 2009 13:29:17 +0200
From:	Peter Feuerer <peter@...e.net>
To:	Borislav Petkov <petkovbb@...glemail.com>
Cc:	LKML <linux-kernel@...r.kernel.org>, lenb@...nel.org,
	Matthew Garrett <mjg59@...f.ucam.org>,
	Maxim Levitsky <maximlevitsky@...il.com>
Subject: Re: [PATCH] Acer Aspire One Fan Control

Hi,

Borislav Petkov writes:

> Hi,
> 
> On Wed, Jun 3, 2009 at 10:10 AM, Peter Feuerer <peter@...e.net> wrote:
>>>> Hm.. I think it should be clear that the fan is turned off, as soon as
>>>> the temperature is below the fanoff temperature. In my opinion printing this
>>>> message would be a case for a "verbose==2" verbose mode :)
>>>
>>> My reasoning was that because this is called from sysfs and the user
>>> sees nothing happening even if he'd turned off the fan by calling
>>> .set_cur_state that it might be useful to tell him why.
>>
>> But the user isn't allowed to change the fan state from userspace anymore.
> 
> Actually, Pavel wanted to have that functionality...

So you think it makes sense to allow it, too? For me it doesn't really 
matter whether user is allowed to change the fan or not. I think controlling 
the fan belongs into kernel, but if the user wants to have his own userspace 
tool I'm fine with this too. So I'll enable userspace control of the fan 
again, ok?

>> If you try to change the fan state from userspace you'll get the "changing
>> fan state is not allowed" message.
> 
> By the way, the system log is being polluted with that message after a
> suspend/resume cycle:
> 
> [99027.020952] acerhdf: failed reading fan state, disabling kernelmode.
> [99027.520172] ACPI: EC: missing confirmations, switch off interrupt mode.
> [99047.672142] acerhdf: changing fan state is not allowed
> [99057.696151] acerhdf: changing fan state is not allowed
> [99067.720125] acerhdf: changing fan state is not allowed
> [99077.744164] acerhdf: changing fan state is not allowed
> [99087.796127] acerhdf: changing fan state is not allowed
> [99097.820147] acerhdf: changing fan state is not allowed
> [99107.844136] acerhdf: changing fan state is not allowed
> [99117.908153] acerhdf: changing fan state is not allowed
> [99127.932155] acerhdf: changing fan state is not allowed
> [99137.123893] [drm:i915_get_vblank_counter] *ERROR* trying to get
> vblank count for disabled pipe 0
> [99137.956075] acerhdf: changing fan state is not allowed
> [99147.980158] acerhdf: changing fan state is not allowed
> [99158.004180] acerhdf: changing fan state is not allowed
> [99168.028148] acerhdf: changing fan state is not allowed
> [99170.207885] [drm:i915_get_vblank_counter] *ERROR* trying to get
> vblank count for disabled pipe 0
> [99178.052149] acerhdf: changing fan state is not allowed
> [99188.076149] acerhdf: changing fan state is not allowed
> [99198.100148] acerhdf: changing fan state is not allowed
> [99208.124150] acerhdf: changing fan state is not allowed
> [99210.558715] acerhdf: kernelmode ON
> [99210.581161] acerhdf: changing fan state is not allowed
> 
> because the suspend/resume cycle is causing the EC error message
> above. In that case, you shouldn't probably switch off kernel mode but
> unregister the driver completely until the EC error is fixed (if ever)... Hmm...

There's a bug in the algorithm which disables the kernelmode in case of 
unexpected register value. → It doesn't stop polling.

And I will re-add suspend / resume code to get rid of the resume problem.

Thanks!

best regards,
--peter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ