> Date: Fri, 16 Apr 2010 22:40:58 +0200
> From: Josselin Mouette <[email protected]>
> To: [email protected]
> Subject: Athlon L110 CPU and powernow-k8
> X-Mailer: Evolution 2.29.92.1
> Message-ID: <1271450458.6794.33.camel@tomoyo>
>
> In both cases, the issue is the same: the DSDT table provided by the
> BIOS does not include the P-states. Waiting for a hypothetical BIOS
> update that would fix this bug requires some faith that I
> don't have. It is possible to work around this by compiling the
> kernel with a custom DSDT table with appropriate P-states patched
> in, however I consider this a developer hack.
>
> I wonder what is possible to do to support this CPU correctly in the
> kernel. The only sane solution I can think of is to hardcode the
> P-states for this CPU model in the powernow-k8 driver itself.
I think that hard-coding P-states into the PowerNow
driver is not a mantainable solution.
I don't quite understand why the you think that
a custom DSDT as a BIOS hack, but think that
adding custom frequencies to the driver itself is
acceptable.
The last time this issue came up on cpufreq, Dave
Jones nixed a general solution to add custom P-states
through the driver on the grounds that people would
undervolt their systems, causing a lot of screwy,
unpredictable behavior. I agreed with his opinion
then and I don't see anything in this mesage to
change that view.
--Mark Langsdorf
Operating System Research Center
AMD
Le lundi 19 avril 2010 à 06:43 -0700, Langsdorf, Mark a écrit :
> > I wonder what is possible to do to support this CPU correctly in the
> > kernel. The only sane solution I can think of is to hardcode the
> > P-states for this CPU model in the powernow-k8 driver itself.
>
> I think that hard-coding P-states into the PowerNow
> driver is not a mantainable solution.
I agree this is not optimal, but I think there are similar bits in other
drivers.
> I don't quite understand why the you think that
> a custom DSDT as a BIOS hack, but think that
> adding custom frequencies to the driver itself is
> acceptable.
The first solution implies building a custom kernel before being able to
use the system. The second solution does not. I’m looking for a solution
that works out of the box, and does not require to be able to compile
ASL code nor a kernel.
> The last time this issue came up on cpufreq, Dave
> Jones nixed a general solution to add custom P-states
> through the driver on the grounds that people would
> undervolt their systems, causing a lot of screwy,
> unpredictable behavior. I agreed with his opinion
> then and I don't see anything in this mesage to
> change that view.
If you want to screw your system, this is already feasible by hacking
the DSDT table itself. Granted, this is not the kind of stuff the
average n00b would do.
Given how Acer doesn’t give a shit about OSes other than XP - not even
other Windows versions - I don’t think they are likely to provide a
fixed BIOS. If they can be convinced, I don’t know how. And if they
can’t - what are we left with?
Cheers,
--
.''`. Josselin Mouette
: :' :
`. `' “If you behave this way because you are blackmailed by someone,
`- […] I will see what I can do for you.” -- Jörg Schilling