Re: [PATCH 2/2] Fix console handling during suspend/resume

[David Brownell <david-b@pacbell.net>]

On Thursday 22 June 2006 4:31 pm, Benjamin Herrenschmidt wrote:
> 

> In fact, most of the problem is resume, not suspend. Most of the time,
> the machine goes to sleep... it just doesn't wakeup. From my experience
> over the years, the main culprit for that have been
> 
>  - USB (anything that bus masters while the memory controller is asleep
> ...
> 
>  - USB (again, sorry David) races and deadlocks etc... though most of
> these have been fixed by now.

No sweat.  ISTR my very first kernel _patch_ was fixing a USB resume
bug (OHCI needed to handle the controller-lost-power case).

Plus, through most of the early 2.6 series I considered USB PM unusable
(without the "rmmod workaround") ... basically because things that worked
in 2.4 were broken by PM core and swsusp changes, and it took time to
sort through all of that along with the higher priority breakage.


Plus, somewhere I produced a list of about eight _orthogonal_ factors
affecting PM on any given x86 platform.  Giving 2^(about eight) different
configurations to test for every PM-related change.  That's painful, and
even I won't make time to test many of those configurations.


>  - cpufreq (this is a design bug with cpufreq with the "core/midlayer"
> trying to get in charge instead of the driers and registering a sysdev
> which is very wrong).

That could stand some elaboration in a separate thread; there are folk
working to enhance cpufreq so that it handles other frequency/voltage
scaling approaches.  I happened to notice that cpufreq isn't even using
the driver model very well, too ...

- Dave