powerd and wlanpacket [PATCH]

[Jerry Vonau]

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.

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

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

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

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

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

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