linux-kernel - Re: Possible bug in eeepc-laptop.c

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]

Message-ID: <71cd59b01003170122h1ef767a3ma186e7ef278d73a1@mail.gmail.com>
Date:	Wed, 17 Mar 2010 09:22:40 +0100
From:	Corentin Chary <corentin.chary@...il.com>
To:	Fabio Comolli <fabio.comolli@...il.com>
Cc:	ACPI mailing list <linux-acpi@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Len Brown <lenb@...nel.org>
Subject: Re: Possible bug in eeepc-laptop.c - EeePC 900

On Tue, Mar 16, 2010 at 9:31 PM, Fabio Comolli <fabio.comolli@...il.com> wrote:
> Hi.
>
> On Tue, Mar 16, 2010 at 7:54 AM, Corentin Chary
> <corentin.chary@...il.com> wrote:
>> On Sat, Mar 13, 2010 at 1:50 PM, Fabio Comolli <fabio.comolli@...il.com> wrote:
>>> Well, I'm confused.
>>>
>>> I rebooted with the "vanilla" eeepc-laptop.c and I'm sorry to say that
>>> the situation it's not like the one I described in the post I wrote 2
>>> days ago. Actually the situation with the patch reverted is the same I
>>> have with the patch applied.
>>>
>>> What I mean is that if I boot on AC power /proc/cpuinfo always reports
>>> 900MHz and 1800 bogomips. It I boot on battery /proc/cpuinfo always
>>> reports 630MHz and 1260 bogomips. Plugging / unplugging the AC does
>>> not change the situation. Only reboot does.
>>>
>>> But the cpufv interface does indeed seem to work, as glxgears and
>>> stellarium show the frame rate change accordingly to the powersave /
>>> performance selection.
>>>
>>> So my question is: what does really the cpufv interface do? Is it
>>> supposed to change the processor frequency? Or does it change
>>> something else?
>>>
>>> And if the answer to the latest question is affirmative, why
>>> /proc/cpuinfo seems to ignore it?
>>>
>>> Sorry for the confusion.
>>> Regards,
>>> Fabio
>>>
>>
>> Here is what I can read in your DSDT:
>>
>> When INIT or _Q31 is called, the bios check the the battery is
>> present, and call FSBA(0) or FSBA(1).
>> _Q31 seems to be called by an hotkey, could you run "acpi_listen" and
>> search the hotkey that generate 0x50 or 0x51 ?
>
> This is the output requested.
>
> hotkey ATKD 0000002e 00000000
> hotkey ATKD 0000002f 00000000
> hotkey ATKD 00000030 00000000
> hotkey ATKD 00000012 00000000
> hotkey ATKD 00000013 00000000
> hotkey ATKD 00000014 00000000
> hotkey ATKD 00000015 00000000
> hotkey ATKD 00000010 00000000
> button/sleep SLPB 00000080 00000001
> hotkey ATKD 00000010 00000001

None of thesed generate 0x50 or 0x51, may be somehting else :/



-- 
Corentin Chary
http://xf.iksaif.net
--
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/