Bug 204850

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

Why must we poll for link dead? Why can't we be sent a signal or poll(2) on
something?

Cool, I'll add this over the weekend.  David: patch welcome :-)

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() 

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 :-(

Created attachment 135520 [details]
Improved patch

This patch should also do the trick, and addresses the issue I pointed out.

fixed

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;
 }

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?

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

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.

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.

Created attachment 139298 [details]
Patch against stable branch (0.6.4); removes fprintfs

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.

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:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=204948#c6

Please consider reopening this bug, or am I missing something?

Can you get the output of:

rpm -qv NetworkManager-gnome

for me?

Thanks.

NetworkManager-gnome-0.6.5-8.fc8

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.

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:
http://www.redhat.com/archives/fedora-devel-list/2007-August/msg01043.html

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.

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

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

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?

(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)
path=/org/freedesktop/NetworkManagerInfo;
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??

Arjan:

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.

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

dhcdbd is no longer in rawhide, so that can't be the case.

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