[Testing] [OLPC-AU] Testing summary, Auckland - 17 March 2012

Jerry Vonau jvonau at shaw.ca
Mon Mar 26 13:44:10 EDT 2012


On Mon, 2012-03-26 at 12:08 -0400, Paul Fox wrote:
> jerry wrote:
>  > On Thu, 2012-03-22 at 09:27 -0400, Paul Fox wrote: 
>  > > jerry wrote:
<snip>
>  > 
>  > I feel that inhibits should not prevent the XO from dimming (think XS on
> 
> but there's almost nothing you can do to fix that in the current
> powerd codebase.  unless you change the order of the timeouts,
> preventing sleep will always prevent dim and blank.  i'm fixing this
> for 12.1.0, but it will have some repercussions -- in particular, some
> activities that inhibit suspend will now dim (think Record, or a movie
> player), and they'll need to do something new to prevent that as well.
> 

Your where I got to be with my mods. :\

>  > XO here), it didn't occur to me that camera usage was being used to
>  > prevent the laptop from dimming.
> 
> seems like having the laptop go to sleep while recording would be pretty
> annoying.
> 

Or watching a streaming video from the internet.

> 
<snip>
>  > The reason I omitted '&& return 0' is because of seeing different
>  > behaviour in cpu_or_network_busy between suspended and not suspended
>  > that the added tracing uncovered. It's true laptop_busy works well
> 
> but you do see that this line:
> 	trace camera cpu_or_network_busy && return 0
> will _always_ return 0, right?  so the reason for omitting it is
> because it's simply wrong -- one doesn't need to observe behavior
> to see that.
> 

Sure, but it pointed me to the real cause 'check_network_activity
finish' is called twice once at laptop_busy where it does prevent
suspend and in the busycheck loop where it does 'break' but not 'break
2' like the other functions there do.

<snip>

>  > 
>  > I should of ran this trace past you first, the logged I added revealed
>  > the difference between the two states. Looks like my cheap hack to
>  > check_camera_activity was just hiding that there appears to be a need to
>  > break out of busycheck's 5 second loop, like inhibited_by_files does to
>  > restore the countdown to 15 seconds thus resetting the idle_counters. 
>  > 
>  > The above tracing is from last week, I have os31 installed and the
>  > behaviour is the same. I'll patch that if you want to see that the
>  > tracing is the same. 
> 
> what kind of packet is causing the wakeup?  i'd like to reproduce this
> on os31.
> 

>From the above trace it clearly shows that the wakeup was wlanpacket:

: @ 1332491482 got wakeup: wlanpacket @ 1332491482, slept 5

I just let the target laptop suspend for a bit and started to ping it.

Why do I even bother supplying the info if your not going to read it,
should I take this off-list and just file a bug instead?

Jerry





More information about the Testing mailing list