[Pm-utils] Trouble waking from sleep

[Dan Nicholson]

On Wed, May 20, 2009 at 4:08 PM, Dan Williams <dcbw at redhat.com> wrote:
> On Wed, 2009-05-20 at 09:40 -0700, Dan Nicholson wrote:
>> On Fri, May 15, 2009 at 4:34 PM, Dan Williams <dcbw at 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).

Good point. I wonder why there's no resume uevent. Hmm, found this old thread:

https://lists.linux-foundation.org/pipermail/linux-pm/2005-March/006504.html

> 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.

Until there's another way, I think it has to be with dbus from
pm-utils. Here's the bug with all the links to the mailing list
discussions and what not. It seems like it's had some traction over
the past couple months.

https://bugs.freedesktop.org/show_bug.cgi?id=896

It would be awesome if you could poke whoever the fedora dbus
maintainer is (davidz?) and try to get that last patch into rawhide
for some testing.

--
Dan