Re: [Pm-utils] Trouble waking from sleep
On Fri, 2009-05-15 at 19:34 -0400, Dan Williams wrote: On Fri, 2009-05-15 at 16:25 +0200, Christopher Lang wrote: Dan, thanks, for pointing me into the right direction, the https://bugzilla.redhat.com/show_bug.cgi?id=477964 has it all. However I would like to point out a few inconsistencies, that are still present in git repositories: 1. git repo from today, NetworkManager: file NetworkManager/initscript/Arch/networkmanager.in This one is using --type=method_call \ in the dbus-send, which is non-blocking, but makes dbus-send use dbus_message_new_method_call to set up the message, rather than dbus_message_new_signal I wasn't aware arch had that functionality actually; that should be fixed. 2. git repo from today, pm-utils: file pm-utils/pm/sleep.d/55NetworkManager This one still has the dbus-send without anything, no --print-reply and no --type=method_call. right, I believe upstream pm-utils was leaning towards fixing dbus rather than this hack, but given that I don't believe upstream dbus will fix the issue soon, we may have to go back to pm-utils upstream and convince them to take the fix. The other thing I was going to do was just to ship the pm-utils files in NetworkManager, thus we can do what we want with them. This is what I prefer -- getting service-specific hooks into the packages that provide them is the Right Thing to do. We have pkg-config support in pm-utils these days, so conditionally building in the hooks should be pretty easy. Dan 3. None of the current git repositores uses the --print-reply as suggested in the above bug report. Conclusion: Using dbus-send to send sleep or wake to NM is causing problems, due to dbus sometimes loosing messages of short lived processes - this is known and confirmed. Using --print-reply in NM related dbus-send calls is confirmed to work, but is highly questionable in my eyes, because it is blocking, worst case this will block for the default dbus timeout value (is that 2 sec. or so?). Using --type=method_call (which is in the NM initscript, but not yet in pm-utils git) might or might not fix the sleep/wake issue that is caused by dbus loosing messages of short lived processes. It forces dbus-send to use: dbus_message_new_method_call dbus_connection_send (connection, message, NULL); dbus_connection_flush (connection); where the flush according to dbus docs blocks until the message queue is empty and so far *should* ensure our sleep or wake to go through. So it should be used in pm-utils too. It is in NM git already. Chris http://www.acurana.de/ ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list ___ Pm-utils mailing list pm-ut...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pm-utils -- Victor Lowther RHCE# 805008539634727 LPIC-2# LPI000140019 ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [Pm-utils] Trouble waking from sleep
On Wed, 2009-05-20 at 09:40 -0700, Dan Nicholson wrote: On Fri, May 15, 2009 at 4:34 PM, Dan Williams d...@redhat.com wrote: On Fri, 2009-05-15 at 16:25 +0200, Christopher Lang wrote: Dan, thanks, for pointing me into the right direction, the https://bugzilla.redhat.com/show_bug.cgi?id=477964 has it all. However I would like to point out a few inconsistencies, that are still present in git repositories: 1. git repo from today, NetworkManager: file NetworkManager/initscript/Arch/networkmanager.in This one is using --type=method_call \ in the dbus-send, which is non-blocking, but makes dbus-send use dbus_message_new_method_call to set up the message, rather than dbus_message_new_signal I wasn't aware arch had that functionality actually; that should be fixed. 2. git repo from today, pm-utils: file pm-utils/pm/sleep.d/55NetworkManager This one still has the dbus-send without anything, no --print-reply and no --type=method_call. right, I believe upstream pm-utils was leaning towards fixing dbus rather than this hack, but given that I don't believe upstream dbus will fix the issue soon, we may have to go back to pm-utils upstream and convince them to take the fix. I don't mind if it has to be done as a workaround in pm-utils, I'm just concerned that it will bitrot and the real fix will never happen. NM (Dan) has been such a huge advocate of fix the drivers instead of papering over it, and I believe that has had a massively positive effect in the long term. I'd at least like to get an idea of what the real issue is with dbus-send and what it would take to get it fixed before pushing this into upstream pm-utils so everyone can have resume slowed down by 2 seconds. The real fix here is to figure out if the kernel sends uevents for resume, and then make NM just listen to those. WE don't really need to do anything on *suspend*, but we do need to know about resume so we can clear the AP lists. We could also trust HAL/udev to tell use about remove/add events that happened while the system was asleep (if they lie, then they need to get fixed themselves to do that). Thus, the only thing we'd care about would be resume, and we could forget pm-utils altogether. If you want to go looking further into D-Bus, Michael Meeks kicked off the discussion about this problem back in March 2008 I believe. Google would probably have his mail and the thread on the dbus devel lists about the issue. But, of course, if we just skip pm-utils altogether we fix the problem too :) Dan The other thing I was going to do was just to ship the pm-utils files in NetworkManager, thus we can do what we want with them. There's already a bug open about this and it's probably the right thing to do, but it just moves the hack from one place to another. -- Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
