Re: [Pm-utils] Trouble waking from sleep

On Wed, May 20, 2009 at 4:08 PM, Dan Williams <dcbw 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 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
>> >> 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/
>> >>
>> >> 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:

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

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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]