On Fri, 19 Oct 2007, Garrett D'Amore wrote:
> James Cornell wrote:
> > On Fri, 2007-10-19 at 11:58 -0700, Garrett D'Amore wrote:
> > Yes +1. It's a pathetic excuse for an OS if it can't do "simple" power
> > management. I understand the plumbing is non-trivial, but no one, not
> > even developers will mass adopt a system that's stuck back in the early
> > 1990's in terms of power management. It's not economical or reasonable
> > to not have the functionality working, out of the box on a major portion
> > of systems in this day and age. With power costs still rising due to
> > demand and overpopulation, and increasing technology advances, support
> > must be achieved.
> >
> > The project will need to abstract hardware support somewhat, as desktop
> > users will also want this functionality, which is an unfortunately
> > larger range of configurations. Main targets would obviously be NVIDIA,
> > and Intel chipsets, and Intel and AMD processors, since they constitute
> > a majority of notebooks and desktops. Every system I've bought OEM wise
> > has been an Intel chipset if it was using an Intel CPU, and I purposely
> > buy Intel motherboards and CPU's when I build systems due to support and
> > to a degree quality concerns. SIS and VIA is not the norm, VIA being
> > more popular than most other non-NVIDIA/Intel chipsets. Most people I
> > know do the same when it comes to chosing or building systems, they go
> > with the best supported configuration, even at a higher price. If it's
> > an AMD, they go with an nForce motherboard, and if it's a Core 2 system
> > they go with an Intel desktop board, or if they're cheap a VIA.
> >
> > General power management features such as Speedstep and AMD's equivalent
> > for dynamic clock speed reduction is another big issue. I have an
> > Ultra-20 with an AMD Opteron 1218, and supposedly this was one of the
> > first systems that should had gotten that feature, it works under
> > Windows and Linux afterall, yes I know, I know, different target and
> > support/development cycle. This applies to notebooks, such as Pentium
> > 4's and newer Core series as well though, since I've noticed it's not
> > even in semi-working state on any system, even the best supported
> > notebooks Sun developers themselves use. I've been keeping track of all
> > the latest ON releases, and hope that soon it'll "Just Work". I
> > shouldn't have to contribute any hardware details given it's a
> > supported/certified and very common system.
> >
> > What do you need from users to help you with this? What do you need
> > from developers in terms of code and input?
> >
>
> From developers, its mostly updating the various drivers (there's a
> bunch of 'em).
>
> From users, help testing, but not *yet*. Really really soon.
>
> Expect to see a desktop version of Suspend-to-Ram for Ultra 20 posted
> shortly. Like next week. Because Randy just submitted his RTI for
> that. :-) We'll be leveraging his work heavily.
>
> -- Garrett
I don't know the amount of time it takes to get code propagated to
OpenSolaris, but there is now code in Solaris that will suspend an
x86!
First caveat: All drivers must comply with the DDI_SUSPEND and
DDI_RESUME commands to their detach(9e)/attach(9e) entry points.
Information about these commands can be found in Chapter 12 of Writing
Device Drivers. For the most part, this cannot be circumvented, as
failure to have all devices comply *and* suspend the machine, *will*
cause the machine to be in a less-than-desirable state on restart.
For most users, they will likely find their framebuffer is the
biggest violator, however, some nVidia Quadro framebuffers will work
with the Solaris or nVidia provided drivers (I am not sure if one is
available on OpenSolaris).
Second caveat: it currently isn't MP enabled. We were having some
interesting MP issues, and rather than try to get them all sorted out,
we disabled them so we can get code back. After that, it is a focused
problem. Note, however, that what we discovered seemed to be random,
so it is quite possible that the problem were BIOS or interesting
hardware configurations. So it does actually work, we just need to
identify and resolve these issues.
Other than that, Ultra 20's (the project reference platform) suspend
in about 2 seconds, and resume in about 7 (all the way to X).
Hopefully I can make binaries or sources available soon, and folks
can start to work out the driver issues that Garrett mentions and we
can clear up the "First caveat".
Cheers!
---- Randy
