[Debian-eeepc-devel] Bug#559578: Bug#559578: Fwd: Bug#559578: eeepc-acpi-scripts: EeePC 701 freezes with garbled screen while booting

[Alan Jenkins]

On 12/9/09, Ben Armstrong <synrg at sanctuary.nslug.ns.ca> wrote:
> On Wed, 9 Dec 2009 11:54:54 +0000
> Alan Jenkins <sourcejedi.lkml at googlemail.com> wrote:
>
>> Hi Corentin
>>
>> It looks like it's not just my 701 which has problems with SHE.  Given
>> that Asus don't support it on the pre-installed OS, I think we should
>> disable it for the 701.
>>
>> <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=559578>.
>
> If by "we", you mean Debian, and by "disable" you mean disable by
> default, then I agree.  However, I don't believe it should be disabled
> upstream.  I have used SHE successfully on the 4G for several weeks.
> Although SHE became suspect when I experienced some lockups, after
> running for a few days with SHE disabled, I still get occasional
> lockups, so I don't no longer think SHE is the cause.  Users ought to
> be given the option of re-enabling it on the 4G, but be given an
> appropriate caution about lack of vendor support for this configuration.
>
> Ben

I think the kernel should disable SHE by default on the 701 models.  I
don't mind if it provides a "force_cpufv" option with an appropriate
warning.

The 701 models aren't shipped with any way to control the SHE.  It is
a form of overclocking which is not supported by the vendor.  On the
other models, SHE is a marketed feature which users will expect to
work reliably.  We should treat these cases differently in the kernel.

I don't think it should be left to userspace to get this right.  There
are other distributions than debian :-).  I've seen at least one
desktop applet which controls SHE.  I expect it has a similar option
to toggle SHE automatically when switching between mains and battery
power.  If we change the kernel, it will affect everyone.

The ABI doc for eeepc-laptop doesn't say "writing to cpufv may break",
so we need _some_ change to the kernel sources :).  I think it's
better to "fix" this in the code and not just add disclaimers in the
documentation.

Alan