Re: [Xpert]Nvidia and Suspend
On Tue, Oct 22, 2002 at 10:37:07PM -0400, David Dawes wrote: > On Tue, Oct 22, 2002 at 09:52:26AM +0200, Ducrot Bruno wrote: > >On Mon, Oct 21, 2002 at 05:14:28PM -0400, David Dawes wrote: > >> On Fri, Oct 18, 2002 at 08:38:22AM +0100, Philip Blacker wrote: > >> >>> I'm wondering if it's feasible for the kernel to route ACPI power > > > > > >[...] > > > >> Does it make a difference if you switch to a text VT before initiating > >> a suspend? That's how XFree86 handles APM suspend/resume. With a > >> correctly implemented VTEnter(), the driver should then reinitalise the > >> hardware correctly when switching back to the X server after resuming. > >> Some drivers don't to enough hw state initialisation in their VTEnter() > >> function to handle returning from suspend. > >> > >> All of this assumes that the BIOS (and OS?) put the video hardware back > >> into a sane text console state -- ideally the same state as after a > >> normal system boot. If that doesn't happen, then there are likely to > >> be problems. > > > >No difference. It is already a common trick for swsusp people. > >I don't see anything in the code that could explain why a perticular > >xaa extension is no more functionnal for this card. > >For me, VTEnter() from the nv driver seems to be correct. > > > >[...] > > > >> >Another way to solve the problem is to start another Xserver on another > >> >display then kill it. This probably does the reset that should come > >> >though APM. > > If VTEnter() is doing everything needed, I'm wondering why starting another > X server then killing it solves the problem. Me too. And the bad news is that I really do not understand what happens here. > >> If swsusp can use some equivalent of apmd (or acpid), it should be > >> possible to have that daemon force a VT switch on suspend, and switch > >> back on resume (using chvt(1) as I suggested above). > >> > >> >I think adding ACPI support to XFree86 is the way to go rather than a > >> >user space deamon. Kernel 2.4.20 is going to have a (almost) fully > >> >working ACPI implementation, the swsusp patch will still be needed for > >> >S4(suspend to disk), S1 (suspend to RAM) will work on some machines. > >> > >> What's the current state of acpid? > > > >Nothing is done from swsusp to send power management notifications to > >user space before suspension. The same apply for ACPI. > > What's the use of acpid if it doesn't get any notifications before > suspension? Is everything that needs to be done expected to be handled > in the kernel? Yes. All processes are 'frozen', then a suspend event to all devices is send. If swsusp want to notify the suspension to user processes, it will require a major redisign at this stage. Same apply also for ACPI (under Linux, I do not speak for *BSD) because it call swsusp (for 2.5 kernels only) to implement S4. -- Ducrot Bruno http://www.poupinou.orgPage profaissionelle http://toto.tu-me-saoules.com Haume page ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Nvidia and Suspend
On Tue, Oct 22, 2002 at 09:52:26AM +0200, Ducrot Bruno wrote: >On Mon, Oct 21, 2002 at 05:14:28PM -0400, David Dawes wrote: >> On Fri, Oct 18, 2002 at 08:38:22AM +0100, Philip Blacker wrote: >> >>> I'm wondering if it's feasible for the kernel to route ACPI power > > >[...] > >> Does it make a difference if you switch to a text VT before initiating >> a suspend? That's how XFree86 handles APM suspend/resume. With a >> correctly implemented VTEnter(), the driver should then reinitalise the >> hardware correctly when switching back to the X server after resuming. >> Some drivers don't to enough hw state initialisation in their VTEnter() >> function to handle returning from suspend. >> >> All of this assumes that the BIOS (and OS?) put the video hardware back >> into a sane text console state -- ideally the same state as after a >> normal system boot. If that doesn't happen, then there are likely to >> be problems. > >No difference. It is already a common trick for swsusp people. >I don't see anything in the code that could explain why a perticular >xaa extension is no more functionnal for this card. >For me, VTEnter() from the nv driver seems to be correct. > >[...] > >> >Another way to solve the problem is to start another Xserver on another >> >display then kill it. This probably does the reset that should come >> >though APM. If VTEnter() is doing everything needed, I'm wondering why starting another X server then killing it solves the problem. >> If swsusp can use some equivalent of apmd (or acpid), it should be >> possible to have that daemon force a VT switch on suspend, and switch >> back on resume (using chvt(1) as I suggested above). >> >> >I think adding ACPI support to XFree86 is the way to go rather than a >> >user space deamon. Kernel 2.4.20 is going to have a (almost) fully >> >working ACPI implementation, the swsusp patch will still be needed for >> >S4(suspend to disk), S1 (suspend to RAM) will work on some machines. >> >> What's the current state of acpid? > >Nothing is done from swsusp to send power management notifications to >user space before suspension. The same apply for ACPI. What's the use of acpid if it doesn't get any notifications before suspension? Is everything that needs to be done expected to be handled in the kernel? David ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Nvidia and Suspend
On Mon, Oct 21, 2002 at 05:14:28PM -0400, David Dawes wrote: > On Fri, Oct 18, 2002 at 08:38:22AM +0100, Philip Blacker wrote: > >>> I'm wondering if it's feasible for the kernel to route ACPI power [...] > Does it make a difference if you switch to a text VT before initiating > a suspend? That's how XFree86 handles APM suspend/resume. With a > correctly implemented VTEnter(), the driver should then reinitalise the > hardware correctly when switching back to the X server after resuming. > Some drivers don't to enough hw state initialisation in their VTEnter() > function to handle returning from suspend. > > All of this assumes that the BIOS (and OS?) put the video hardware back > into a sane text console state -- ideally the same state as after a > normal system boot. If that doesn't happen, then there are likely to > be problems. No difference. It is already a common trick for swsusp people. I don't see anything in the code that could explain why a perticular xaa extension is no more functionnal for this card. For me, VTEnter() from the nv driver seems to be correct. [...] > >Another way to solve the problem is to start another Xserver on another > >display then kill it. This probably does the reset that should come > >though APM. > > > >Is there a way for a user space program to signal to the X server that > >a suspend is about to happen or that a resume has happend to enable > >this reset to be done more cleanly. > > Currently the X server only monitors the APM device for power management > events. > > If swsusp can use some equivalent of apmd (or acpid), it should be > possible to have that daemon force a VT switch on suspend, and switch > back on resume (using chvt(1) as I suggested above). > > >I think adding ACPI support to XFree86 is the way to go rather than a > >user space deamon. Kernel 2.4.20 is going to have a (almost) fully > >working ACPI implementation, the swsusp patch will still be needed for > >S4(suspend to disk), S1 (suspend to RAM) will work on some machines. > > What's the current state of acpid? Nothing is done from swsusp to send power management notifications to user space before suspension. The same apply for ACPI. -- Ducrot Bruno http://www.poupinou.orgPage profaissionelle http://toto.tu-me-saoules.com Haume page ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Nvidia and Suspend
On Fri, Oct 18, 2002 at 08:38:22AM +0100, Philip Blacker wrote: >>> I'm wondering if it's feasible for the kernel to route ACPI power >>>management events to the corresponding APM events through /dev/apm >>>(optionally, of course) for some sort of ACPI to APM backwards >>>compatibility for some apps that use /dev/apm (like XFree86). >>>Otherwise somebody will have to add /dev/acpi support to XFree86. > >>It might be feasible to do this in user space too with a daemon that >>listens on /dev/acpi and delivers translated events on /dev/apm. >>Ultimately we probably want to add ACPI support to XFree86 so that it >>can take full advantage of what ACPI offers over APM. > >>I think the original poster mentioned swsusp, which I thought was >>independent of APM and ACPI? I don't know what (if any) mechanism it >>uses to inform interested user-space applications that a suspend has >>been initiated. Either the X server needs to be informed about the >>suspend and resume so that it can do what needs to do, or have >something >>else does get informed use chvt(1) to make the X server VT switch to >>a text console on suspend and switch back on resume. I think the chvt > >>method is what people used before XFree86 had support for monitoring >>APM events. > >>David > >Swsusp is totally independant of ACPI and APM, although it can be >called by either. I am not sure if it fires an APM or ACPI event if >these are enabled. > >Through the swsusp mailing list it has been esatblished that the prblem >is with XAA, or more specifically with one XAA function, >SolidTwoPointLine. If this is disabled everything works correctly. It >apears that the hardware acceleration gets confused during the suspend/ >resume cycle. Does it make a difference if you switch to a text VT before initiating a suspend? That's how XFree86 handles APM suspend/resume. With a correctly implemented VTEnter(), the driver should then reinitalise the hardware correctly when switching back to the X server after resuming. Some drivers don't to enough hw state initialisation in their VTEnter() function to handle returning from suspend. All of this assumes that the BIOS (and OS?) put the video hardware back into a sane text console state -- ideally the same state as after a normal system boot. If that doesn't happen, then there are likely to be problems. >It has also been reported that when using the closed source driver, >patched so that is does not block power management events, the 3d >functinality does not work immediately after resume but will start >working some time later. This would imply that there is a problem with >the nvidia hardware after a resume that requires some form of reset. > >Another way to solve the problem is to start another Xserver on another >display then kill it. This probably does the reset that should come >though APM. > >Is there a way for a user space program to signal to the X server that >a suspend is about to happen or that a resume has happend to enable >this reset to be done more cleanly. Currently the X server only monitors the APM device for power management events. If swsusp can use some equivalent of apmd (or acpid), it should be possible to have that daemon force a VT switch on suspend, and switch back on resume (using chvt(1) as I suggested above). >I think adding ACPI support to XFree86 is the way to go rather than a >user space deamon. Kernel 2.4.20 is going to have a (almost) fully >working ACPI implementation, the swsusp patch will still be needed for >S4(suspend to disk), S1 (suspend to RAM) will work on some machines. What's the current state of acpid? David ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Nvidia and Suspend
On Sun, Oct 20, 2002 at 02:52:16PM -0700, Mark Vojkovich wrote: > On Fri, 18 Oct 2002, Philip Blacker wrote: > > > >> I'm wondering if it's feasible for the kernel to route ACPI power > > >>management events to the corresponding APM events through /dev/apm > > >>(optionally, of course) for some sort of ACPI to APM backwards > > >>compatibility for some apps that use /dev/apm (like XFree86). > > >>Otherwise somebody will have to add /dev/acpi support to XFree86. > > > > >It might be feasible to do this in user space too with a daemon that > > >listens on /dev/acpi and delivers translated events on /dev/apm. > > >Ultimately we probably want to add ACPI support to XFree86 so that it > > >can take full advantage of what ACPI offers over APM. > > > > >I think the original poster mentioned swsusp, which I thought was > > >independent of APM and ACPI? I don't know what (if any) mechanism it > > >uses to inform interested user-space applications that a suspend has > > >been initiated. Either the X server needs to be informed about the > > >suspend and resume so that it can do what needs to do, or have > > something > > >else does get informed use chvt(1) to make the X server VT switch to > > >a text console on suspend and switch back on resume. I think the chvt > > > > >method is what people used before XFree86 had support for monitoring > > >APM events. > > > > >David > > > > Swsusp is totally independant of ACPI and APM, although it can be > > called by either. I am not sure if it fires an APM or ACPI event if > > these are enabled. > > > > Through the swsusp mailing list it has been esatblished that the prblem > > is with XAA, or more specifically with one XAA function, > > SolidTwoPointLine. If this is disabled everything works correctly. It > > apears that the hardware acceleration gets confused during the suspend/ > > resume cycle. > >The bios does something to the hardware when it goes into suspend > that messes up the graphics engine state. At this time, I don't know > what it is that it does. swsusp is a legacy interface to implement suspend-to-disk feature to linux. No APM call is then done. ACPI (only in linux 2.5) use this legacy interface to implement S4, and call the necessary (as for example the _PTS ASL Methods before suspension, _WAK after resuming, etc) No such things is done, though in linux 2.4 + swsusp. Please note that the same trouble can occur with FreeBSD current, with a S4BIOS suspend/resume cycle, and yes, a system state snapshoot is done by the BIOS in that case. > > > > > It has also been reported that when using the closed source driver, > > patched so that is does not block power management events, the 3d > > functinality does not work immediately after resume but will start > > working some time later. This would imply that there is a problem with > > the nvidia hardware after a resume that requires some form of reset. > >Same problem. Bios messes things up and we have no way of > knowing about it. In the case of the binary drivers it's not safe > to run with the power management unblocked because when the bios > messes with the hardware it can do things that effect the kernel > module in a fatal way (lost interrupts and the like). > It is possible to inform the binary driver that a suspension can occur via ACPI. The function RmPowerManagement() in the binary portion were supposed to be called by ACPI. This function seems to be in the NVIDIA_kernel-1.0.2314 release, but is now removed. If this function is (re)implemented for linux 2.5, suspend/resume via ACPI can be done for this card. Please note also that there were efforts to have proper suspend/resume under ACPI with the help of drm for other cards. Cheers, -- Ducrot Bruno http://www.poupinou.orgPage profaissionelle http://toto.tu-me-saoules.com Haume page ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Nvidia and Suspend
On Thu, Oct 17, 2002 at 02:21:13PM -0700, Mark Vojkovich wrote: >On Fri, 18 Oct 2002, Brad Hards wrote: > >> On Fri, 18 Oct 2002 05:35, Mark Vojkovich wrote: >> >The "nv" driver doesn't know (and can't know) anything about >> > suspend events. It's handled entirely by the bios and there is >> > no mechanism for XFree86 to get these ACPI events from the kernel. >> > Subsequently, the bios will mess up the "nv" driver's state and >> > the "nv" driver won't know that it needs to be reinitialized. >> > You have to VT switch to clean things up. I think the only solution >> > to this problem is to have ACPI support in the kernel and >> > have the events routed to /dev/apm (which XFree86 supports) or >> > to some other device and have XFree86 add support for that device. >> >> Tim Hockin wrote a acpid (on sourceforge.net) that can take ACPI events from >> the kernel ( via /proc/acpi/event ) and runs things in userspace. That is a >> potentially useful approach in this case. >> >> I see something like this (generalised to handle many other events), along >> with the current Linux hotplug style approach, as the path to make X work in >> dynamic hardware and networking environments. >> > > I'm wondering if it's feasible for the kernel to route ACPI power >management events to the corresponding APM events through /dev/apm >(optionally, of course) for some sort of ACPI to APM backwards >compatibility for some apps that use /dev/apm (like XFree86). >Otherwise somebody will have to add /dev/acpi support to XFree86. It might be feasible to do this in user space too with a daemon that listens on /dev/acpi and delivers translated events on /dev/apm. Ultimately we probably want to add ACPI support to XFree86 so that it can take full advantage of what ACPI offers over APM. I think the original poster mentioned swsusp, which I thought was independent of APM and ACPI? I don't know what (if any) mechanism it uses to inform interested user-space applications that a suspend has been initiated. Either the X server needs to be informed about the suspend and resume so that it can do what needs to do, or have something else does get informed use chvt(1) to make the X server VT switch to a text console on suspend and switch back on resume. I think the chvt method is what people used before XFree86 had support for monitoring APM events. David ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Nvidia and Suspend
On Fri, 18 Oct 2002, Brad Hards wrote: > On Fri, 18 Oct 2002 05:35, Mark Vojkovich wrote: > >The "nv" driver doesn't know (and can't know) anything about > > suspend events. It's handled entirely by the bios and there is > > no mechanism for XFree86 to get these ACPI events from the kernel. > > Subsequently, the bios will mess up the "nv" driver's state and > > the "nv" driver won't know that it needs to be reinitialized. > > You have to VT switch to clean things up. I think the only solution > > to this problem is to have ACPI support in the kernel and > > have the events routed to /dev/apm (which XFree86 supports) or > > to some other device and have XFree86 add support for that device. > > Tim Hockin wrote a acpid (on sourceforge.net) that can take ACPI events from > the kernel ( via /proc/acpi/event ) and runs things in userspace. That is a > potentially useful approach in this case. > > I see something like this (generalised to handle many other events), along > with the current Linux hotplug style approach, as the path to make X work in > dynamic hardware and networking environments. > I'm wondering if it's feasible for the kernel to route ACPI power management events to the corresponding APM events through /dev/apm (optionally, of course) for some sort of ACPI to APM backwards compatibility for some apps that use /dev/apm (like XFree86). Otherwise somebody will have to add /dev/acpi support to XFree86. Mark. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Nvidia and Suspend
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 18 Oct 2002 05:35, Mark Vojkovich wrote: >The "nv" driver doesn't know (and can't know) anything about > suspend events. It's handled entirely by the bios and there is > no mechanism for XFree86 to get these ACPI events from the kernel. > Subsequently, the bios will mess up the "nv" driver's state and > the "nv" driver won't know that it needs to be reinitialized. > You have to VT switch to clean things up. I think the only solution > to this problem is to have ACPI support in the kernel and > have the events routed to /dev/apm (which XFree86 supports) or > to some other device and have XFree86 add support for that device. Tim Hockin wrote a acpid (on sourceforge.net) that can take ACPI events from the kernel ( via /proc/acpi/event ) and runs things in userspace. That is a potentially useful approach in this case. I see something like this (generalised to handle many other events), along with the current Linux hotplug style approach, as the path to make X work in dynamic hardware and networking environments. Brad - -- http://linux.conf.au. 22-25Jan2003. Perth, Aust. I'm registered. Are you? -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9ryBbW6pHgIdAuOMRAomlAJwNut8160A2irfoRM/dEOwbC7QR9QCfaggN 10YvoL6wxwZmLrF2nix8fvU= =z1U/ -END PGP SIGNATURE- ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Nvidia and Suspend
The "nv" driver doesn't know (and can't know) anything about suspend events. It's handled entirely by the bios and there is no mechanism for XFree86 to get these ACPI events from the kernel. Subsequently, the bios will mess up the "nv" driver's state and the "nv" driver won't know that it needs to be reinitialized. You have to VT switch to clean things up. I think the only solution to this problem is to have ACPI support in the kernel and have the events routed to /dev/apm (which XFree86 supports) or to some other device and have XFree86 add support for that device. Mark. On Wed, 16 Oct 2002 [EMAIL PROTECTED] wrote: > I am using Gentoo 1.4 with Xfree 4.2.1, with the patch for the > Geforce2Go on > a dell 8100. > > I am running kernel 2.4.19 patched with the swsusp patch, but have seen > the > same effect on 2.4.18. > > When I resume from a suspend I find that the Gtk theme is not applied > properly, in fact certain widgets do not have any theming applied to > them. > If I switch to another theme and back to the original, the theme is > then > displayed properly. However, after another suspend/resume cycle I > cannot > switch to this theme and back again I have to use another one. > > I looks as though Gtk caches the themes via the driver and the driver > is not restoring or saving its memory properly. > > This effect has been confirmed by a number of people on the swsusp list, > > including one person reporting problems with KDE. > > > Phil > ___ > Xpert mailing list > [EMAIL PROTECTED] > http://XFree86.Org/mailman/listinfo/xpert > ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Nvidia and Suspend
I am using Gentoo 1.4 with Xfree 4.2.1, with the patch for the Geforce2Go on a dell 8100. I am running kernel 2.4.19 patched with the swsusp patch, but have seen the same effect on 2.4.18. When I resume from a suspend I find that the Gtk theme is not applied properly, in fact certain widgets do not have any theming applied to them. If I switch to another theme and back to the original, the theme is then displayed properly. However, after another suspend/resume cycle I cannot switch to this theme and back again I have to use another one. I looks as though Gtk caches the themes via the driver and the driver is not restoring or saving its memory properly. This effect has been confirmed by a number of people on the swsusp list, including one person reporting problems with KDE. Phil ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
