Hey Paul:
I'm back, and I think I can explain this now once you patch powerd for
some better logging around set_wake_on_wlan, that would be patch 1.
> jerry wrote:
> > Hi Paul:
> >
> > I'll see if I can be clearer in my explanation.
> >
> > On Mon, 2012-02-20 at 08:47 -0500, Paul Fox wrote:
> > > hi jerry --
> > >
> > > jerry wrote:
> > > > Hi All:
> > > >
> > > > While working with powerd in debug mode I noticed that "wlanpacket"
> > > > would always cause a break in snooze(). I realized that
> > >
> > > yes -- that 'break' is intentional, but perhaps you're observing
> something
> > > i didn't expect?
> > >
> >
> > Yes, I realize this break is intentional. Maybe I am, we'll see ;)
> >
> > > my thinking was, if we don't break out of that loop when we're woken
> > > up for 'wlanpacket', there's a fair chance that we'll go right back to
> > > sleep without the system fully processing the packet we just received.
> > > it seemed prudent to stay awake longer. so the packet arrival is
> > > treated similarly to new user activity (except that it won't brighten
> > > the screen if it's been dimmed.) are you saying that this isn't needed?
> > >
> >
> > Yes, that is my point, I'll see if I can communicate my thought better.
> >
Think it would be best to set_wake_on_wlan as early as possible. The
only time that set_wake_on_wlan was being run is just at wlan_associated
which I think is a little late. While tailing powerd.trace from tty2
with patch 1 you can see the that wlan_associated is the only place that
is was getting set. The problem is just after that occurs you have DCON
taking over and I think the ethtool and DCON are in a race condition,
the userspace may become frozen too soon for ethtool to set the wlan
card correctly.
Patch 2 does coming out of suspend, while patch 3 does the same thing
early in the initialization process. Patch 4 covers when the network
maybe becomes unavailable and needs to be reset. Patch 5 is for improved
logging around wlanpacket to support my idea that the info should not be
acted upon.
Patch 6 disables the call to set_wake_on_wlan at wlan_associated as this
wol has already been set, or to disable wol if you don't want blanked
wakeups.
> > > > prepare_for_wakeupsource() was reading $WAKEUP_SOURCE which I believe
> is
> > >
> > > i think you mean get_wakeupsource()?
> >
> > Yes, sorry that is what I meant, easy to lose what your looking at and
> > trying to type after looking at tracing for too long. lol..
> >
> > >
> > > > feedback from the firmware.
> >
> > Since $WAKEUP_SOURCE exists on 2.6.35(XO-1.5), the wakeup type is
> > recorded in a field in the kernel that tells the reason for the last
> > wakeup. I don't think this field is reset until there is a new entry.
> > There could be an entry several seconds old.
>
> right. it's not updated until the next wakeup.
>
I think $wakeupsource should be discarded if it is wlanpacket, the WLAN
card already knows it is busy servicing the network. We just have to
trigger the needed rtcwake call.
> >
> > > > Noticed that the sleep was 6-8 second, just
> > > > a bit longer than BUSYCHECK.
> >
> > When BUSYCHECK is done its loop in cpu_or_network_busy() snooze() is
> > called next where get_wakeupsource reads $WAKEUP_SOURCE. The entry
> > present in $WAKEUP_SOURCE may in fact be from the last BUSYCHECK and
> > actually older that the time spent in the just ended BUSYCHECK.
>
> get_wakeupsource is called after rtcwake returns -- i.e., after we've
> suspended. so i don't see how it can ever be stale. i.e., the flow is
> sleep_action()
> laptop_busy
> cpu_or_network_busy()
> BUSYCHECK loop
> snooze
> set_wakeup_events
> prepare_for_wakeupsource
> ...
> rtcwake
> ...
> get_wakeup_source
>
>
> perhaps there's still some dyslexia regarding the pair of
> prepare_for_wakeupsource() / get_wakup_source() ? the former
> is a null routine on xo-1 and 1.5.
>
I think $wakeupsource should be discarded if it is wlanpacket
> >
> > > > That is why when you disable WAKE_ON_WLAN
> > > > the XOs will go to sleep, until-sleep_type does toggle to the next
> stage
> > > > as until_blank-soft after rtcalarm appears in $wakeupsource.
> >
> > Now if $wake_on_wlan is set, "wlanpacket" gets a fake_useractive, gets
> > logged, you never get to "rtcalarm" and the XO doesn't dim or blank.
> > Tried testing the XO where it's the only one on the AP to rule out a
> > chatty network as the source of the wlanpacket with no change in the
> > above noted 6-8 second wlanpacket break in snooze.
>
> so i gather you're seeing what you believe to be spurious wlanpacket
> wakeups.
>
No, not really, the wakeups are happening, we just shouldn't trigger a
reset_idlecounters at this point. That's what will result if we break
from that loop.
> >
> > > > I believe
> > > > the message need to be ignored at this point, and to just use
> > > > cpu_or_network_busy() to determine if the laptop blanks or not.
> > >
> >
> > If there is net traffic present, $monitor_network_activity should be
> > able to prevent until-sleep_type from progressing to the next stage.
>
> you may well be right about this. but i'm still not sure how reducing
> the time we spend awake will improve the laptop's performance on the
> network.
>
Actually we what to progress to the next stage, to allow the screen to
dim or blank.
> >
> > > sorry. i've tried a couple of times to follow you through that
> > > paragraph, and i keep losing you. disabling WAKE_ON_WLAN will keep
> > > the laptop from waking up on wlan traffic.
> >
> > Not really, `ethtool eth0` reports wol as 'd' anyway. (that is a another
> > issue), but $monitor_network_activity does catch active connections or
> > pings.
>
> on 2.6.35 kernels, the ethtool wol wakeup conditions are lost after
> every resume, so we're careful to reestablish those wakeups (i.e.,
> we call ethtool again) on every suspend. this seems to be fixed in
> 3.0 and later kernels.
>
Patch 2 should take care of that.
> >
> > > i'm pretty sure that if
> > > you do that, you'll never get the 'wlanpacket' event that your patch
> > > affects. so i'm confused.
> > >
> >
> > Well if wlanpacket wakes the XO needlessly, is there really a point to
> > trusting its feedback?
> >
> > > perhaps i don't understand the goal. i thought the problem you were
> having
> > > with your deployments was that idle suspend was interfering with
> collaboration.
> > > what's the problem we're trying to solve here?
> > >
> >
> > DCON likes to kick in rendering the WLAN card unavailable, when it comes
> > back online every 11 seconds or so NetworkManager is forced to renew its
> > dhcp lease again. This is another issue. Think that network traffic is
> > unneeded, and may lead to excessive network loading of the dhcp server.
>
> when you say "DCON likes to kick in rendering the WLAN card
> unavailable", are you saying that the wlan becomes unavailable when
> the laptop goes to sleep? does the network light go out? do you
> need to reassociate on every wakeup?
>
Think this was related to the late setting of wol.
> this sounds like a networkmanager issue. if you're reassociating and
> renewing your lease after every resume, i can well imagine you're having
> connectivity problems.
>
> paul
>
> >
> > > (and, for completeness, on which laptop? i think you're working with
> > > 1.5 machines is that right?)
> > >
> >
> > I'm working on XO-1.5s currently, but I have XO-1 and XO-1.75 to test
> > with also. Hope I've been clearer in my explanation this time.
> >
> > Jerry
> >
> >
>
> =---------------------
> paul fox, p...@laptop.org
FWIW in running TIME_SLEEP="15" TIME_DIM="60" TIME_BLANK="60"
WAKE_ON_WLAN="yes WLAN_WAKE_FROM_BLANK_IDLE_SLEEP="yes"
Jerry
--- usr/sbin/powerd.orig 2012-02-22 11:51:20.000000000 -0600
+++ usr/sbin/powerd 2012-02-22 06:39:28.905196031 -0600
@@ -1258,15 +1258,20 @@
# "netstat -l --inet -n | grep -q ':5298 '"
if grep -qi ": 00000000:14B2" /proc/net/tcp
then
+ trace set_wake_on multicast
ethtool -s $WLANIFACE wol um;
else
+ trace set_wake_on unicast
ethtool -s $WLANIFACE wol u;
fi
;;
no)
+ trace set_wake_on disabled
ethtool -s $WLANIFACE wol d
;;
esac
+ TOOLRESULTS=`ethtool $WLANIFACE`
+ trace ethtool $TOOLRESULTS
}
wlan_associated()
@@ -1662,6 +1667,8 @@
# been enabled in the first place.
if [ "$wake_on_wlan" ]
then
+ TOOLRESULTS=`ethtool $WLANIFACE`
+ trace ethtool hard $TOOLRESULTS
set_wake_on_wlan no
fi
fi
@@ -1673,6 +1680,8 @@
if [ "$wake_on_wlan" ]
then
+ TOOLRESULTS=`ethtool $WLANIFACE`
+ trace ethtool associated $TOOLRESULTS
# wake on wlan if we're only waiting for dim or
# blank. else we're already blank, so w-o-l if we've
# been asked to and we're currently associated with
@@ -1681,7 +1690,10 @@
( yes_or_true $config_WLAN_WAKE_FROM_BLANK_IDLE_SLEEP && \
wlan_associated )
then
+ trace wlan_associated
set_wake_on_wlan yes
+ else
+ trace NOT wlan_associated
fi
fi
;;
@@ -1798,6 +1810,7 @@
if [ "$wake_on_wlan" ]
then
selfinject fake_useractive $lastwakeup "$wakeupsource"
+ trace wlanpacket used during $until
break
fi
;;
@@ -2326,7 +2339,10 @@
# force w-o-l off, because later we skip turning it off if it
# shouldn't be on according to current config.
+ TOOLRESULTS=`ethtool $WLANIFACE`
+ trace ethtool initial $TOOLRESULTS
set_wake_on_wlan no
+
wake_on_wlan=$(yes_or_true_to_boolean "$config_WAKE_ON_WLAN")
sleep_on_close=$(yes_or_true_to_boolean "$config_SLEEP_WHEN_LID_CLOSED")
--- usr/sbin/powerd-1wip 2012-02-26 02:48:15.003724420 -0600
+++ usr/sbin/powerd 2012-02-26 02:52:52.687126659 -0600
@@ -887,7 +887,7 @@
log powerd $powerd_version startup at $(date), on XO-$XO
log $(< /proc/version)
log olpc build: $(< /boot/olpc_build)
-
+trace startup at $(date)
yes_or_true()
{
@@ -1256,6 +1256,7 @@
yes)
# detect telepathy/salut, and wake on multicast if present.
# "netstat -l --inet -n | grep -q ':5298 '"
+ trace setting wol
if grep -qi ": 00000000:14B2" /proc/net/tcp
then
trace set_wake_on multicast
@@ -1745,7 +1746,14 @@
done
# this is it. here's where we suspend or sleep.
- rtcwake -s$rtctime -mmem -d $rtcdevice
+ rtcwake -s $rtctime -mmem -d $rtcdevice
+
+ if [ "$wake_on_wlan" ]
+ then
+ TOOLRESULTS=`ethtool $WLANIFACE`
+ trace ethtool rtcwake $TOOLRESULTS
+ set_wake_on_wlan yes
+ fi
# we need SCI events, because they do more than just
# provide wakeup -- they drive input events as well.
--- usr/sbin/powerd-2wip 2012-02-26 03:26:58.000000000 -0600
+++ usr/sbin/powerd 2012-02-26 03:36:40.342042702 -0600
@@ -2909,6 +2909,12 @@
;;
*)
dcon thaw
+ if [ "$wake_on_wlan" ]
+ then
+ TOOLRESULTS=`ethtool $WLANIFACE`
+ trace ethtool boot $TOOLRESULTS
+ set_wake_on_wlan yes
+ fi
;;
esac
dcon_thawed=true
--- usr/sbin/powerd-3wip 2012-02-26 03:48:33.062783416 -0600
+++ usr/sbin/powerd 2012-02-26 03:46:02.824932536 -0600
@@ -1918,6 +1918,11 @@
reset_idlecounters
runparts resume &
+ if [ "$wake_on_wlan" ]
+ then
+ TOOLRESULTS=`ethtool $WLANIFACE`
+ trace ethtool resume $TOOLRESULTS
+ fi
}
if [ "$no_dcon" ]
@@ -2934,6 +2939,12 @@
allow-suspend)
: $(( no_suspend = (no_suspend > 0) ? no_suspend - 1 : 0 ))
+ if [ "$wake_on_wlan" ]
+ then
+ TOOLRESULTS=`ethtool $WLANIFACE`
+ trace ethtool allowed $TOOLRESULTS
+ set_wake_on_wlan yes
+ fi
;;
ambient-adjust)
--- usr/sbin/powerd-4wip 2012-02-26 03:46:02.000000000 -0600
+++ usr/sbin/powerd 2012-02-26 03:32:13.854579545 -0600
@@ -1817,9 +1817,25 @@
"wlanpacket")
if [ "$wake_on_wlan" ]
then
- selfinject fake_useractive $lastwakeup "$wakeupsource"
- trace wlanpacket used during $until
- break
+ case $until in
+ until_dim)
+# selfinject fake_useractive $lastwakeup "$wakeupsource"
+ trace wlanpacket ignore during $until
+ ;;
+
+ until_blank)
+# selfinject fake_useractive $lastwakeup "$wakeupsource"
+ trace wlanpacket ignore during $until
+ ;;
+
+ until_shutdown)
+# selfinject fake_useractive $lastwakeup "$wakeupsource"
+ trace wlanpacket ignore during $until
+ ;;
+ *)
+ trace wlanpacket not matched during $until
+ ;;
+ esac
fi
;;
--- usr/sbin/powerd-5wip 2012-02-26 03:56:56.822807820 -0600
+++ usr/sbin/powerd 2012-02-26 10:07:02.000000000 -0600
@@ -1692,9 +1692,9 @@
wlan_associated )
then
trace wlan_associated
- set_wake_on_wlan yes
else
- trace NOT wlan_associated
+ trace NOT wlan_associated or don't blank on wakeup
+ set_wake_on_lan no
fi
fi
;;
_______________________________________________
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
