Re: peculiar suspend/resume bug.

[Nigel Cunningham <ncunningham@linuxmail.org>]

Hi Dave.

On Tue, 2006-08-15 at 20:37 -0400, Dave Jones wrote:
> On Wed, Aug 16, 2006 at 10:19:59AM +1000, Nigel Cunningham wrote:
>  > Hi Dave.
>  > 
>  > On Tue, 2006-08-15 at 18:10 -0400, Dave Jones wrote:
>  > > Here's a fun one.
>  > > - Get a dual core cpufreq aware laptop (Like say, a core-duo)
>  > > - Add a cpufreq monitor to gnome-panel. Configure it
>  > >   to watch the 2nd core.
>  > > - Suspend.
>  > > - Resume.
>  > > 
>  > > Watch the cpufreq monitor die horribly.
>  > > 
>  > > I believe this is because we take down the 2nd core at suspend
>  > > time with cpu hotplug, and for some reason we're scheduling
>  > > userspace before we bring that second core back up.
>  > > 
>  > > Anyone have any clues why this is happening?
>  > 
>  > If you hotunplug and replug the cpu using the sysfs interface, rather
>  > than suspending and resuming, does the same thing happen?
> 
> cpufreq-applet crashes as soon as the cpu goes offline.
> Now, the applet should be written to deal with this scenario more
> gracefully, but I'm questioning whether or not userspace should
> *see* the unplug/replug that suspend does at all.
> 
> IMO, when we shouldn't schedule userspace until the system is
> in the exact state it was before we suspended.

At the moment, the cpu hotplugging/unplugging is done outside of
freezing processes because once we've frozen processes we can't (afaik)
move ones that are tied to the cpu being unplugged to another processor,
and won't also be able to kill kernel threads that are tied to the
processor(s) being taken down.

Personally, I wouldn't mind being seeing this addressed as I see a few
other benefits to being able to hot[un]plug later, besides simplifying
life for the cpufreq-applet (although it shouldn't crash if a cpu is
offlined anyway).

Regards,

Nigel