reassing 733545 cpufreqd
retitle 733545 cpufreqd should honour bios_limit when setting max/min freq
thanks
On Mon, Dec 30, 2013 at 12:55:00PM +0900, Mattia Dongili wrote:
> On Mon, Dec 30, 2013 at 04:30:33AM +0100, Ben Hutchings wrote:
> > Which scaling driver is being used?
>
> acpi-cpufreq
>
> > Which scaling governor are you using?
>
> ondemand
>
> > What was the last kernel version where this worked?
>
> I don't know, I usually just leave ondemand do it's work without
> interfering. I looked at this because of the bugreport sent to cpufreqd.
>
> below the output of cpufreq-info that includes stats. The oddity is
> these two frequencies:
> 1801000 1800000
or maybe the kernel is right and cpufreqd/libcpufreq should start
understanding "bios_limit":
$ grep . /sys/devices/system/cpu/cpu0/cpufreq/*
/sys/devices/system/cpu/cpu0/cpufreq/affected_cpus:0
/sys/devices/system/cpu/cpu0/cpufreq/bios_limit:1800000
grep: /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq: Permission denied
/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq:1801000
/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_min_freq:800000
...
/me reads docs and commit e2f74f355
" This interface is mainly intended (and implemented) for ACPI _PPC BIOS
frequency limitations, but other cpufreq drivers can also use it for
similar use-cases.
Why is this needed:
Currently it's not obvious why cpufreq got limited.
People see cpufreq/scaling_max_freq reduced, but this could have
happened by:
- any userspace prog writing to scaling_max_freq
- thermal limitations
- hardware (_PPC in ACPI case) limitiations
"
Martin,
this may be the second and third cases could be why you can't always
reproduce the issue?
Briging this back to cpufreqd.
(although the behaviour of succeeding when writing 1801000 and actually
not being able to set it is questionable... but well)
--
mattia
:wq!
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
