> > Since Suspend failed on driver support to cpr, I am CC to driver-discuss. > > Thanks, > Venu.
Hopefully, there will be more support and information on driver-discuss, as it does appear as if the issue is with your framebuffer using a driver that supports suspend and resume. More below > > Venu C wrote: > > Randy Fishel wrote: > >> On Tue, 14 Oct 2008, Venu Chennupati wrote: > >> > >> > >>> Is the cpr(suspend-resume) is supported on Solaris x86 platform?. > >>> when I tried > >>> "/usr/openwin/bin/sys-suspend" and selected "suspend" operation, got > >>> notified > >>> suspend is not supported. > >>> > >>> Is there any otherway to enable it or the cpr is not supported on x86. > >>> > >>> Thanks, > >>> Venu. > >>> > >> > >> > >> It is supported, but it may or may not work on your particular > >> platform. Check the FAQ's at the OpenSolaris Power Management > >> Community pages for help in getting it configured for your machine, > >> and if you still have problems, come back and ask. > >> > >> http://opensolaris.org/os/community/pm/ > >> > > I have updated /etc/power.conf with the line "S3-support enable". > > Seems like > > cpr is enabled post pmconfig/reboot. But the suspend fails for a > > display device: > > > > Oct 20 11:13:41 lippert genunix: [ID 535284 kern.notice] System is > > being suspended > > Oct 20 11:13:42 lippert genunix: [ID 122848 kern.warning] WARNING: > > Unable to suspend device [EMAIL PROTECTED] > > Oct 20 11:13:42 lippert genunix: [ID 537702 kern.warning] WARNING: > > Device is busy or does not support suspend/resume. > > Oct 20 11:13:44 lippert cpr: [ID 208601 kern.notice] > > Oct 20 11:13:44 lippert The system is back where you left! > > Oct 20 11:13:44 lippert genunix: [ID 583038 kern.notice] System has > > been resumed. > > > > The display is based on Intel Graphics Controller(0x8086, 0x8108) and > > its info is below: > > > > display, instance #0 (driver name: vgatext) This is the primary issue with this particular suspend failure. vgatext does not support suspend/resume, because it is a generic driver with no knowlege of how to restore hardware state. So any machine with 'vgatext' as the framebuffer driver will fail (other isues are further below). The question for driver-discuss, is whether this actual hardware should have used a different driver, specifically i915 (as is is the current common Intel framebuffer driver)? It might be that you just need a driver update. (refer to original message for remainder of driver properties) > > > > System Configuration: Sun Microsystems i86pc > > Memory size: 1015 Megabytes > > System Peripherals (Software Nodes): > > > > i86pc (driver name: rootnex) > > scsi_vhci, instance #0 (driver name: scsi_vhci) > > isa, instance #0 (driver name: isa) > > motherboard > > pit_beep, instance #0 (driver name: pit_beep) > > pci, instance #0 (driver name: npe) > > pci8086,7270 > > display, instance #0 (driver name: vgatext) > > pci8086,7270 > > pci8086,7270, instance #0 (driver name: audiohd) > > pci8086,8110, instance #0 (driver name: pcie_pci) > > pci8086,1000, instance #0 (driver name: wpi) > > pci8086,8112, instance #1 (driver name: pcie_pci) > > pci10b5,8112, instance #2 (driver name: pcie_pci) > > pci8086,1209, instance #0 (driver name: iprb) > > pci1283,8888 > > pci1000,12 (driver name: symhisl) > > pci8086,7270, instance #0 (driver name: uhci) > > pci8086,7270, instance #1 (driver name: uhci) > > pci8086,7270, instance #2 (driver name: uhci) > > pci8086,7270, instance #0 (driver name: ehci) > > hub, instance #1 (driver name: hubd) > > device, instance #2 (driver name: usb_mid) > > mouse, instance #4 (driver name: hid) > > input, instance #5 (driver name: hid) > > device, instance #3 (driver name: usb_mid) > > keyboard, instance #6 (driver name: hid) > > input, instance #7 (driver name: hid) > > pci8086,7270 (driver name: sdhost) > > pci8086,7270 (driver name: sdhost) > > pci8086,7270 (driver name: sdhost) > > pci8086,7270 > > pci-ide, instance #0 (driver name: pci-ide) > > ide, instance #0 (driver name: ata) > > cmdk, instance #0 (driver name: cmdk) > > ide (driver name: ata) > > iscsi, instance #0 (driver name: iscsi) > > pseudo, instance #0 (driver name: pseudo) > > options, instance #0 (driver name: options) > > agpgart, instance #0 (driver name: agpgart) > > xsvc, instance #0 (driver name: xsvc) > > used-resources > > cpus, instance #0 (driver name: cpunex) > > cpu, instance #0 (driver name: cpudrv) > > cpu, instance #1 (driver name: cpudrv) From this list, I see that you will still have a problem with iprb, as it still does not support suspend and resume. And I don't know what 'symhisl' is, so I don't know if this will be a problem or not. However, it does look like the rest are supported drivers. > > > > I remember using the sequence on sparc (uadmin 3 101, uadmin 3 102, > > uadmin 3 0) > > flags 101, 102 give more details on cpr operation, is it still > > supported on x86 platform? These test points are only usable on Sparc platforms. There is one x86 test point that might be of interest to you and other driver developers, and that is the "22" function (i.e. 'uadmin 3 22'). This goes through the suspend path, but does not actually call the _S3 method, and instead returns as a successful suspend. It provides a way to test that driver paths are good, and that all drivers comply before actually doing the power-off for suspend. It doesn't test if the drivers actually restore hardware correctly, but will show that they try. It is useful as the first attempt to suspend (note, though, that this must be run as root). > > > > > > Thanks, > > Venu. > > > >> > >> Cheers! (again) > >> > >> > >> ---- Randy > >> _______________________________________________ driver-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/driver-discuss
