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: <b637ec0b1003161331y680418e0p6549504165a45701@mail.gmail.com>
Date:	Tue, 16 Mar 2010 21:31:14 +0100
From:	Fabio Comolli <fabio.comolli@...il.com>
To:	Corentin Chary <corentin.chary@...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

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

>
> FSBA is the method called by CFVS. When you do "echo 1 > cpufv" it
> calls CFVS(1), then FSBA(1).
> FSBA got 2 presets on 900.
>
> Using these presets, is write some bytes to the EC and to something
> wich sounds like clock (RCLK, WCKB, WLCK)
> By the name it seems that it set the FSB, it may also surely change
> the CPU Clock.
>
> Now, I don't know why cpuinfo always show the same value, maybe
> because the cpu clock is not changed
> by a cpufreq driver.

Well, the cpuinfo frequency value seems to be set only at boot: 630 if
booting from battery, 900 from AC.

>
> --
> Corentin Chary
> http://xf.iksaif.net
>

Thanks,
Fabio
--
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