Hi,
On Friday, 4 of February 2005 00:15, Rafael J. Wysocki wrote:
> On Thursday, 3 of February 2005 15:22, Pavel Machek wrote:
[-- snip --]
> > > I'm currently thinking that the proper approach may be to add a
> > > ->suspend()
> > > routine to struct cpufreq_driver and call the driver-specific
On Friday, 4 of February 2005 00:34, Nigel Cunningham wrote:
> Hi.
>
> On Fri, 2005-02-04 at 10:15, Rafael J. Wysocki wrote:
> > Instead of trying to blow up the battery I used the patch that forces the
> > CPU
> > to 800 MHz and it apparently survives resuming on batteries - at least 3
> > times
Hi,
On Thursday, 3 of February 2005 23:00, Pavel Machek wrote:
> Hi!
>
> > > You may not run k8 notebook on max frequency on battery. Your system
> > > will crash; and you might even damage battery.
> >
> > When I don't compile in cpufreq, it seems to run at 1,8 GHz (the max)
> > all the time, o
Hi.
On Fri, 2005-02-04 at 10:15, Rafael J. Wysocki wrote:
> Instead of trying to blow up the battery I used the patch that forces the CPU
> to 800 MHz and it apparently survives resuming on batteries - at least 3
> times out of 3 attempts (I'll try some times more tomorrow).
>
> It seems to boot
On Thursday, 3 of February 2005 15:22, Pavel Machek wrote:
> Hi!
>
> > > > So, would it be acceptable to check in _suspend() if the state is S4
> > > > and drop the frequency in that case or do nothing otherwise?
> > >
> > > No. The point is that this is _very_ system-specific. Some systems resum
Hi!
> > You may not run k8 notebook on max frequency on battery. Your system
> > will crash; and you might even damage battery.
>
> When I don't compile in cpufreq, it seems to run at 1,8 GHz (the max)
> all the time, on AC power as well as on battery. Along with what you're
> saying it leads to
Hi!
> > You may not run k8 notebook on max frequency on battery. Your system
> > will crash; and you might even damage battery.
>
> When I don't compile in cpufreq, it seems to run at 1,8 GHz (the max)
> all the time, on AC power as well as on battery. Along with what you're
> saying it leads to
On Thursday, 3 of February 2005 15:20, Pavel Machek wrote:
> Hi!
>
> > > > > > On Thu, Feb 03, 2005 at 11:41:26AM +0100, Pavel Machek wrote:
> > > > > > > Okay, you are right, restoring it unconditionaly would be bad
> > > > > > > idea. Still it would be nice to tell cpufreq governor "please
> >
Hi!
> > > So, would it be acceptable to check in _suspend() if the state is S4
> > > and drop the frequency in that case or do nothing otherwise?
> >
> > No. The point is that this is _very_ system-specific. Some systems resume
> > always at full speed, some always at low speed; for S4 the behavi
Hi!
> > > > > On Thu, Feb 03, 2005 at 11:41:26AM +0100, Pavel Machek wrote:
> > > > > > Okay, you are right, restoring it unconditionaly would be bad
> > > > > > idea. Still it would be nice to tell cpufreq governor "please change
> > > > > > the frequency ASAP" so it does not run at 800MHz for ha
On Thursday, 3 of February 2005 13:40, Dominik Brodowski wrote:
[-- snip --]
> > So, would it be acceptable to check in _suspend() if the state is S4
> > and drop the frequency in that case or do nothing otherwise?
>
> No. The point is that this is _very_ system-specific. Some systems resume
> alw
On Thu, Feb 03, 2005 at 12:30:19PM +0100, Rafael J. Wysocki wrote:
> On Thursday, 3 of February 2005 12:01, Dominik Brodowski wrote:
> > On Thu, Feb 03, 2005 at 11:58:46AM +0100, Pavel Machek wrote:
> > > Hi!
> > >
> > > > On Thu, Feb 03, 2005 at 11:41:26AM +0100, Pavel Machek wrote:
> > > > > Oka
On Thursday, 3 of February 2005 12:01, Dominik Brodowski wrote:
> On Thu, Feb 03, 2005 at 11:58:46AM +0100, Pavel Machek wrote:
> > Hi!
> >
> > > On Thu, Feb 03, 2005 at 11:41:26AM +0100, Pavel Machek wrote:
> > > > Okay, you are right, restoring it unconditionaly would be bad
> > > > idea. Still
On Thu, Feb 03, 2005 at 11:58:46AM +0100, Pavel Machek wrote:
> Hi!
>
> > On Thu, Feb 03, 2005 at 11:41:26AM +0100, Pavel Machek wrote:
> > > Okay, you are right, restoring it unconditionaly would be bad
> > > idea. Still it would be nice to tell cpufreq governor "please change
> > > the frequency
Hi!
> On Thu, Feb 03, 2005 at 11:41:26AM +0100, Pavel Machek wrote:
> > Okay, you are right, restoring it unconditionaly would be bad
> > idea. Still it would be nice to tell cpufreq governor "please change
> > the frequency ASAP" so it does not run at 800MHz for half an hour
> > compiling kernels
Hi,
On Thu, Feb 03, 2005 at 11:41:26AM +0100, Pavel Machek wrote:
> Okay, you are right, restoring it unconditionaly would be bad
> idea. Still it would be nice to tell cpufreq governor "please change
> the frequency ASAP" so it does not run at 800MHz for half an hour
> compiling kernels on AC pow
Hi!
> > > I have noticed that the condition (cur_freq != cpu_policy->cur), which is
> > > unlikely() according to cpufreq.c:cpufreq_resume(), occurs on every resume
> > > on my box (Athlon64-based Asus). Every time the box resumes, I get a
> > > message
> > > like that:
> > >
> > > Warning: CPU
On Wednesday, 2 of February 2005 14:31, Pavel Machek wrote:
> Hi!
>
> > I have noticed that the condition (cur_freq != cpu_policy->cur), which is
> > unlikely() according to cpufreq.c:cpufreq_resume(), occurs on every resume
> > on my box (Athlon64-based Asus). Every time the box resumes, I get a
Hi!
> I have noticed that the condition (cur_freq != cpu_policy->cur), which is
> unlikely() according to cpufreq.c:cpufreq_resume(), occurs on every resume
> on my box (Athlon64-based Asus). Every time the box resumes, I get a message
> like that:
>
> Warning: CPU frequency out of sync: cpufreq
Hi,
I have noticed that the condition (cur_freq != cpu_policy->cur), which is
unlikely() according to cpufreq.c:cpufreq_resume(), occurs on every resume
on my box (Athlon64-based Asus). Every time the box resumes, I get a message
like that:
Warning: CPU frequency out of sync: cpufreq and timing
20 matches
Mail list logo
