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
