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

Paul Fox pgf at laptop.org
Mon Mar 26 14:01:27 EDT 2012


jerry wrote:
 > 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.

argh!  that's almost certainly a bug.  sigh.  i believe that should be a
"break 2", just like the one above it.  :-/

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

i wasn't asking about the cause of the wakeup -- i was asking
specifically what _kind_ of packet, and now you've told me it was a
ping.  i wanted to be sure it was a packet that would normally have
kept us awake.

that one was clearly a simple miscommunication, but i apologize if i
have trouble following the results of your testing in detail.  you've
made lot of (iterative, in come cases) changes to your version of
powerd, so i'm never quite sure what you're running.  and over time
you haven't always been clear on what problem(s), exactly, you're
attempting to address.  i want to help, but i can't necessarily
recreate your environment to the letter.

paul
=---------------------
 paul fox, pgf at laptop.org


More information about the OLPC-NZ mailing list