Randy Fishel wrote: > 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 > > Cool, I have an Ultra-20, that's great progress, and I'm sure it's almost complete in OpenSolaris to the public if that's the case, I doubt there's many legal qualms with the code given the bucks Sun drives to NVIDIA.
James
