Re: [Pm-utils] Trouble waking from sleep

[Dan Williams <dcbw redhat com>]

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