Re: processors core stuck in full throttle after waking up from s2ram

["Justin P. Mattock" <justinmattock@gmail.com>]

On Sun, 2008-11-23 at 18:24 +0100, Pavel Machek wrote:
> Hi!
> 
> 
> > > > the processor is full throttle on one of the cores.
> > > 
> > > Surely not.  The first core shows 2.16 GHz.
> > > 
> > > Anyway, it certainly is not related to the s2ram program in any way.
> > 
> > 
> > Normally I would see cpu MHz: 1000 under both entries,
> > this time upon wakeup theres 1000 and 2167.00. the 2167.00 doesn't move
> > down to 1000 i.g. example of system normally:
> >  cat /proc/cpuinfo <below>
> 
> 
> > will move between 2167.00 to 1000 simultaneously under load with both
> > cores, but then back down to 1000, for both when settled down.
> > in this situation as I reported, the 2167.00 just
> > stays at that number for one of the cores(if thats what I'm seeing) when
> > waking up from suspend for some reason or another. 
> 
> Can you check with top that no process is running/eating time?
> 
> If you change cpufreq governor to powersave, will it react?
> 
> Can you check with powertop if the cpu is idle (C2/C3)or if it is
> running something?
> 
> Actually, booting with nosmp might be useful. Is it always same core?

>From what I'm seeing now, the issue seems to be resolved.
(between commits:2.6.28-rc5-00118-geef8eed
and 2.6.28-rc6-00011-g3791555 seems to have fixed this,
although I don't know what commit was the successful commit); 

As for processes happening upon wakeup,
I can try and see with top.
(I'm certain though that the video card switches to full
throttle upon wakeup, i.g. when starting the system I use
"./radeontool power low" to lower the video cards power, so she's not too
hot; after waking up "./radeontool power status", reveals that those settings
go back to it's default, full throttle with the card). When this issue
was occurring this aspect made no difference.

As for switching between cpufreq_ondemand and cpufreq_powersave:
I did, when this issue was happening, 
I did a watch cat /proc/cpuinfo(saw the one core stuck)
then in another terminal issue the command:
powersave -e Powersave, then powersave -l
which puts the box into cpufreq_powersave mode.
when looking at the other terminal watching cpuinfo
I had noticed that the core that was stuck, moved down in frequency,
then a few seconds later move back up to it's full frequency,
and stayed there. 

As for finding a solution, 
My goal yesterday was to downgrade the xserver to use an older video
module, to see if this was graphics module, or something else("isolate the issue"); 
So now after being unable to reproduce this,
(before git-pulling yesterday it was vary reproducible) 
And feeling like a dunce, I'm going to just run s2ram
numerous times, to see if this occurs and report any interesting
anomalies.
  
regards;

-- 
Justin P. Mattock <justinmattock@gmail.com>