Bug 204850 - [patch] nm-applet wakes up every second FOR NO REASON
[patch] nm-applet wakes up every second FOR NO REASON
Product: Fedora
Classification: Fedora
Component: NetworkManager (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Christopher Aillon
: Reopened
Depends On:
Blocks: wakeup
  Show dependency treegraph
Reported: 2006-08-31 17:19 EDT by Arjan van de Ven
Modified: 2007-11-30 17:11 EST (History)
3 users (show)

See Also:
Fixed In Version: 1:0.6.4-6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-10-24 23:42:27 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
patch to fix nm-applet to not make it wake up once per second to realize it has nothing to do (1.40 KB, patch)
2006-08-31 17:19 EDT, Arjan van de Ven
no flags Details | Diff
Improved patch (3.26 KB, patch)
2006-09-04 23:26 EDT, Christopher Aillon
no flags Details | Diff
Make all timeouts smart (12.32 KB, patch)
2006-10-24 22:15 EDT, Dan Williams
no flags Details | Diff
Patch against stable branch (0.6.4); removes fprintfs (12.43 KB, patch)
2006-10-24 22:28 EDT, Dan Williams
no flags Details | Diff

  None (edit)
Description Arjan van de Ven 2006-08-31 17:19:02 EDT
Description of problem:

if you don't have NM active (as is default in FC6), you still get nm-applet,
because NM could become active later. That's fair enough.
However the nm-applet decides to wake up every second to redraw it's icon, and
then realizes NM still isn't active. Waking every second is not fun with the
tickless idle kernel; the aim is to save power by not waking up and if every app
on the system has several 1Hz timers, the aggregate is going insane (a normal
gnome desktop with 1 app currently has about 300Hz worth of these).

The attached patch tries to at least reduce the sillyness by killing the redraw
timer when NM isn't active, and kicking it back alive when NM becomes active.
Also it increases the "is the link dead" timer to 10 seconds; that's still
plenty for such a rare event.
Comment 1 Arjan van de Ven 2006-08-31 17:19:02 EDT
Created attachment 135335 [details]
patch to fix nm-applet to not make it wake up once per second to realize it has nothing to do
Comment 2 David Woodhouse 2006-09-01 12:40:05 EDT
Why must we poll for link dead? Why can't we be sent a signal or poll(2) on
Comment 3 Christopher Aillon 2006-09-01 17:21:21 EDT
Cool, I'll add this over the weekend.  David: patch welcome :-)
Comment 4 Arjan van de Ven 2006-09-02 04:57:23 EDT
if/when the patch from 205008 gets merged, the link dead timer should obviously
use the new g_timeout_add_approx() API rather than g_timeout_add() 
Comment 5 Christopher Aillon 2006-09-04 23:23:56 EDT
Just looked at the patch... there's an issue with never setting the
redraw_timeout_id to 0, so we'd end up in a situation like:

service NetworkManager start; # redraw starts
service NetworkManager stop; # redraw stops
service NetworkManager start; # no redraw :-(

Comment 6 Christopher Aillon 2006-09-04 23:26:12 EDT
Created attachment 135520 [details]
Improved patch

This patch should also do the trick, and addresses the issue I pointed out.
Comment 7 Christopher Aillon 2006-09-05 01:05:36 EDT
Comment 8 Arjan van de Ven 2006-10-09 13:31:07 EDT
Unfortunately this isn't quite enough... the following is needed to really fix it ;(

--- applet.c.org        2006-10-09 19:26:15.000000000 +0200
+++ applet.c    2006-10-09 19:26:11.000000000 +0200
@@ -1177,7 +1177,10 @@ static int nma_redraw_timeout (NMApplet
        if (!applet->animation_id)
                nma_update_state (applet);

-       return TRUE;
+       if (applet->nm_running)
+               return TRUE;
+       else
+               return FALSE;

Comment 9 Christopher Aillon 2006-10-09 13:43:48 EDT
That should be handled by:

+	else if (!applet->nm_running && applet->redraw_timeout_id)
+	{
+		g_source_remove (applet->redraw_timeout_id);
+		applet->redraw_timeout_id = 0;
+	}

Are you seeing results to the contrary?
Comment 10 Arjan van de Ven 2006-10-09 15:23:02 EDT
yes; without the patch nm-applet still wakes up every second; with the patch it
doesn't anymore.. So while I believe your intent is right, it's not actually
working well ...
Comment 11 Dan Williams 2006-10-24 22:15:56 EDT
Created attachment 139297 [details]
Make all timeouts smart

How about this patch?  It also tries to whack the always-on 10s timeout for
dbus reconnection.
Comment 12 Dan Williams 2006-10-24 22:19:21 EDT
The redraw timeout should be event-driven of course.  That won't help much right
now because NM is stupid about signal strength updates.  It currently pushes out
signal strength updates every 1s or whenever scan results come in.  Cards that
background scan (like the ipw2xxx and ipw3xxx cards) push scan events out more
often than once per second, and that makes NM push out strength updates more
than once per second, which in turn would make event-driven applet updates
pretty useless until NM gets fixed.

NM should probably push out signal strength updates once every 5 seconds or so max.
Comment 13 Dan Williams 2006-10-24 22:28:38 EDT
Created attachment 139298 [details]
Patch against stable branch (0.6.4); removes fprintfs
Comment 14 Dan Williams 2006-10-24 23:42:27 EDT
I've committed a slightly modified version of the patch in Comment 13 to CVS for
both HEAD and stable (0.6.x).  I'll also add the patch to FC-5, FC-6, and devel.
 Let me know if you see problems in the patch above.
Comment 15 William Lovaton 2007-08-14 10:16:44 EDT
Are you sure this bug is fixed?  I still see 1 wake up every second from
nm-applet.  See the attachment in Bug #204948 comment #6:

Please consider reopening this bug, or am I missing something?
Comment 16 Dan Williams 2007-08-14 10:26:53 EDT
Can you get the output of:

rpm -qv NetworkManager-gnome

for me?

Comment 17 William Lovaton 2007-08-14 22:51:36 EDT

This is rawhide as of August 13.  I still need to apply the latest updates but I
guess it won't make any difference... I'll report back later if it does.
Comment 18 William Lovaton 2007-08-15 08:44:06 EDT
Tried updating to yesterdays Rawhide (Aug 14) and dhcdbd-2.9-1.fc8 broke
terribly making NetworkManager to fail constantly on startup so now I don't have
a network connection,  see this thread:
Comment 19 William Lovaton 2007-08-19 13:38:42 EDT
The problem in the previous comment is now solved and I updated to
NetworkManager-gnome-0.6.5-9.fc8 as of today Rawhide.  The problem is still
present, "nm-applet : schedule_timeout (process_timeout)" is causing 1 wake up
per second according to powertop.
Comment 20 William Lovaton 2007-08-26 17:04:22 EDT
Dan, is there something new about this one? I updated to latest Rawhide today
and nm-applet is still waking up the cpu every second
Comment 21 Dan Williams 2007-08-27 15:43:26 EDT
There shouldn't be a ton new.  Can you run 'dbus-monitor --system' and attach
the log and also give an impression of how often the lines scroll by?  It may be
that the strength is changing frequently (NM should gate that and only update it
every 5 seconds or so) or that you have an ipw card that pushes out scan results
at a very high rate (whcih they do when background scanning when not connected).
Comment 22 Arjan van de Ven 2007-08-27 16:26:22 EDT
question: what should I tell the ipw driver guys to do? Eg what is the right 
thing that you expect the wireless card to do?
Comment 23 William Lovaton 2007-08-27 22:53:32 EDT
(In reply to comment #21)
> There shouldn't be a ton new.  Can you run 'dbus-monitor --system' and attach
> the log and also give an impression of how often the lines scroll by?  It may be
> that the strength is changing frequently (NM should gate that and only update it
> every 5 seconds or so) or that you have an ipw card that pushes out scan results
> at a very high rate (whcih they do when background scanning when not connected).

Dan, There is a little miss understanding on your part: this is an old desktop
computer with no wireless connection.  The only option in nm-applet is the
"Wired network" and still it wakes up 1 time every second according to powertop.
 I even tried disabling networking by unchecking "Enable Networking" and still
there is 1 wps.

lspci show that my network card is:
00:0a.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL-8139/8139C/8139C+ (rev 10)

and 'dbus-monitor --system' only shows the following line only:
signal sender=org.freedesktop.DBus -> dest=:1.23 path=/org/freedesktop/DBus;
interface=org.freedesktop.DBus; member=NameAcquired
   string ":1.23"

One way to make it log something additional is clicking on the nm-applet icon. 
It then shows the following:
signal sender=:1.16 -> dest=(null destination)
interface=org.freedesktop.NetworkManagerInfo; member=UserInterfaceActivated

So there seems to be no special activity by NM.  As far as I can tell there
should be only 1 wakeup every 5 seconds but power top show 1 every second:
0.6% (  1.0)         nm-applet : schedule_timeout (process_timeout)

What's powertop showing on your system??
Comment 24 Dan Williams 2007-08-28 08:35:17 EDT

So the issue is this...  ipw2100 and ipw2200 cards do background scanning when
not associated, which is great.  I like that.  Each time the card gets new scan
results, it's supposed to generate an SIOCGIWSCAN event and push it to userspace
so that userspace can get the new BSSID.  That's all fine.

The actual _problem_ is that the driver doesn't aggregate these events
adequately.  If you run 'iwevent' on a system with an un-associated ipw2x00
card, you'll see this.  Every userspace process that listens for wireless events
over netlink will get poked every time the driver sends out a new event.  This
means that things like wpa_supplicant and NetworkManager wake up at least once
per second to handle the event.

If the ipw2x00 driver just stuck the background scanning SIOCGIWSCAN event
emission on a delayed workqueue or something that batched up the events and
fired max every 2 - 4 seconds, that would be a lot better.  There's really no
reason to care about an SIOCGIWSCAN event that frequently, since normal scans
take 2 - 4 seconds anyway.
Comment 25 William Lovaton 2007-09-08 08:33:05 EDT
Maybe the problem I'm reporting has something to do with dhcdbd waking up 1 time
per second just as nm-applet.  I think both processes are related somehow.

The thing is that I am connecting my desktop computer to a wired network without
any wireless device and still it is waking up every second which is exactly the
problem suggested by the subject of this bug report.

Maybe this bug report should be reopened.  (BTW, I am testing latest RAWHIDE as
of today).
Comment 26 Christopher Aillon 2007-10-04 12:34:30 EDT
dhcdbd is no longer in rawhide, so that can't be the case.
Comment 27 Dan Williams 2007-10-09 14:03:11 EDT
Arjan: I just posted a patch to linux-wireless that batches together ipw2200
background scan events that should stop it from waking up processes like
wpa_supplicant many times per second with WEXT scan result notifications.

Subject: 	[PATCH] ipw2200: batch non-user-requested scan result notifications
Date: 	        Tue, 09 Oct 2007 13:55:24 -0400

Note You need to log in before you can comment on or make changes to this bug.