powerd and wlanpacket [PATCH]

[Paul Fox]

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

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

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

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

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

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

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, pgf at laptop.org