[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