Re: [linux-pm] Re: [RFC] powermac: proper sleep management
Isn't it true that the freezer _already_ isn't enabled on PPC? So leaving it off wouldn't break anything more than it is broken now. Indeed. johannes signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [linux-pm] Re: [RFC] powermac: proper sleep management
On Mon, 12 Nov 2007, Johannes Berg wrote: Looks good to me, +/- a couple of things: - We _REALLY_ want the freezer to be optional and not enabled by default on PowerPC. Maybe make it a compile option ? Well, Alan is going to tell you that USB will break. If we need confirmation for that I can do the test he suggested to you or Paul a while ago. Isn't it true that the freezer _already_ isn't enabled on PPC? So leaving it off wouldn't break anything more than it is broken now. Alan Stern ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [linux-pm] Re: [RFC] powermac: proper sleep management
On Tue, 13 Nov 2007, Benjamin Herrenschmidt wrote: On Mon, 2007-11-12 at 17:32 +0100, Johannes Berg wrote: Looks good to me, +/- a couple of things: - We _REALLY_ want the freezer to be optional and not enabled by default on PowerPC. Maybe make it a compile option ? Well, Alan is going to tell you that USB will break. If we need confirmation for that I can do the test he suggested to you or Paul a while ago. Then USB is broken today on powermacs and need to be fixed. We had a clear agreement at KS this year that the freezer was at best a band-aid and that drivers -had- to be fixed to cope regardless. More accurately, freezing user tasks is at best a band-aid. However some kernel threads do need to be frozen, and keeping the freezer around for their use makes sense. It has less overhead -- I think -- than adding new code to do the freezing in each of these threads. (It's true that USB drivers in general aren't written to operate in a freezerless system-suspend environment. That's a harder problem and it will have to be fixed driver-by-driver, over time. The same may be true for lots of non-USB char device drivers as well. Pick your favorite char device driver: How will it behave if a user task submits an I/O request after the device has been suspended?) Alan Stern ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [linux-pm] Re: [RFC] powermac: proper sleep management
On Mon, 2007-11-12 at 15:40 -0500, Alan Stern wrote: On Tue, 13 Nov 2007, Benjamin Herrenschmidt wrote: On Mon, 2007-11-12 at 17:32 +0100, Johannes Berg wrote: Looks good to me, +/- a couple of things: - We _REALLY_ want the freezer to be optional and not enabled by default on PowerPC. Maybe make it a compile option ? Well, Alan is going to tell you that USB will break. If we need confirmation for that I can do the test he suggested to you or Paul a while ago. Then USB is broken today on powermacs and need to be fixed. We had a clear agreement at KS this year that the freezer was at best a band-aid and that drivers -had- to be fixed to cope regardless. More accurately, freezing user tasks is at best a band-aid. However some kernel threads do need to be frozen, and keeping the freezer around for their use makes sense. It has less overhead -- I think -- than adding new code to do the freezing in each of these threads. I remember fixing various issues so that khubd would be safe when non frozen (among other things) a while ago. Did you guys break it all again ? Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [linux-pm] Re: [RFC] powermac: proper sleep management
On Tue, 13 Nov 2007, Benjamin Herrenschmidt wrote: I remember fixing various issues so that khubd would be safe when non frozen (among other things) a while ago. Did you guys break it all again ? Sorry, I don't know what fixes you're referring to. But come to think of it, some changes I added to the PM core a few months ago (locking every device prior to system sleep) would also make khubd and ksuspend_usbd safe, since they acquire the device lock before trying to resume anything. So I take back what I said. It's no longer true that those two USB kernel threads need to be frozen for system sleep. (I should test and make sure that really works...) But aren't there other kernel threads scattered around that still want to be frozen? For instance, drivers/misc/tifm_core.c calls create_freezeable_workqueue(). And set_freezable() gets called in lots of places. Alan Stern ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
