[OLPC New Zealand] [OLPC-AU] [Testing] Testing summary, Auckland - 17 March 2012
Paul Fox
pgf at laptop.org
Mon Mar 26 12:08:34 EDT 2012
jerry wrote:
> On Thu, 2012-03-22 at 09:27 -0400, Paul Fox wrote:
> > jerry wrote:
> > > On Wed, 2012-03-21 at 16:13 -0400, Paul Fox wrote:
> > > > tabitha wrote:
> > > > > Testing Summary, Auckland - 17 March 2012
> > > > > Who: Fabiana, John, Oliver, Rachel, Tom
> > > > >
> > > > > Tested build 30 customized on XO-1.75 and build 206 11.3.1-au on XO 1.5.
> > > > >
> > > > > XO-1.5 Summary (details below):
> > > > > Power saving blanks the screen while recording a video
> > > > ...
> > > > > build 206 11.3.1-au on XO 1.5:
> > > > > Rosella:
> > > > > Record activity - works fine for photo and video. high and low res.
> > > > > even long ones. But quite quickly the screen goes black - it is not
> > > > > going to sleep - there is no flashing of the power light and it
> > > > > continues recording. On Ivy it takes 1 minute to go black. Tabitha
> > > >
> > > > jerry vonau tells me that the powerd version in this release is
> > > > based on my powerd-44. i cannot reproduce this problem with our
> > > > os31 running with either powerd 44 or 46.
> > > >
> > > > i don't know where to find the au modified packages, so i can't
> > > > test the specific version that was being run above.
> > > >
> > >
> > > Hi Paul,
> >
> > jerry -- i think i've asked twice now (okay, i suppose it was just
> > implied, above) for a pointer to the modified version of powerd that
> > was included in your build 206. where can i find that code?
> >
>
> I'll dig that up, I forgot to branch the public git repo at that point
> in time. I've placed copies of what was in au206, au207 in the public
> git repo.
thanks.
>
> > >
> > > I was tracking down why my XO-1.5's would never dim/blank in the normal
> > > course of operation with version 46. I chose to modify version 44 as I
> >
> > so you're working on a different problem than the one above. the problem
> > above is that the screen _does_ dim and blank when Record is active.
> >
>
> 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.
> 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.
> >
> > r3-patch:
> > > diff --git a/powerd b/powerd
> > > index bf595d3..e849f87 100755
> > > --- a/powerd
> > > +++ b/powerd
> > > @@ -1010,7 +1010,9 @@ else
> > > test $1 = "finish" && \
> > > grep -q via-dma /proc/interrupts && \
> > > trace camera busy
> > > + return 0
> > > }
> > > + return 1
> > > fi
> >
> > you've a) forced check_camera_activity() to always return 0, and b)
> > added a "return 1" outside of the body of the function. so this
> > doesn't seem right.
>
> I used the behaviour of the XO-1 routine just above as a guide, return 0
> for busy else return 1. I have removed that modification from the
> patches for the next image au210.
>
>
> >
> > >
> > >
> > > @@ -1151,7 +1153,7 @@ cpu_or_network_busy()
> > > trace network cpu_or_network_busy
> > >
> > > check_camera_activity finish
> > > - trace camera cpu_or_network_busy && return 0
> > > + trace camera cpu_or_network_busy
> > >
> > > return 1
> > > }
> >
> > here you've fixed the issue i mentioned regarding r2-patch, so that
> > you're no longer checking the return value of a trace call. that's
> > good. but you're still not checking the value of check_camera_activity
> > at all, which i guess is why you didn't notice that it's always
> > returning success.
> >
>
> 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.
> before a suspend is done as shown below.
>
> #### Start pre-suspended ####
>
> : @ 1332491401 got wakeup: keypress @ 1332491401, slept 17
> Running disable_mesh.sh resume
> : @ 1332491402 got event: useractive, 1332491401, , , .
> : @ 1332491402 backlight restore
> : @ 1332491402 got event: fake_useractive, 1332491401, keypress, , .
> : @ 1332491402 backlight restore
> : @ 1332491411 got event: timer, 1332491411, 60, , .
> : @ 1332491412 got event: useridle1, 1332491412, , , .
> : @ 1332491412 general inhibit: 0
> : @ 1332491412 start cpu_or_network_busy
> : @ 1332491412 loop cpu_or_network_busy
> : @ 1332491417 busycheck cpu_or_network_busy
> : @ 1332491417 cpu cpu_or_network_busy
> : @ 1332491417 network busy
> : @ 1332491417 laptop_busy TRUE
> : @ 1332491427 got event: useridle1, 1332491427, , , .
> : @ 1332491427 general inhibit: 0
> : @ 1332491427 start cpu_or_network_busy
> : @ 1332491427 loop cpu_or_network_busy
> : @ 1332491432 busycheck cpu_or_network_busy
> : @ 1332491432 cpu cpu_or_network_busy
> : @ 1332491432 network busy
> : @ 1332491432 laptop_busy TRUE
> : @ 1332491442 got event: useridle1, 1332491442, , , .
> : @ 1332491442 general inhibit: 0
> : @ 1332491442 start cpu_or_network_busy
> : @ 1332491442 loop cpu_or_network_busy
> : @ 1332491447 busycheck cpu_or_network_busy
> : @ 1332491447 cpu cpu_or_network_busy
> : @ 1332491447 network cpu_or_network_busy
> : @ 1332491447 camera cpu_or_network_busy
> : @ 1332491447 laptop_busy FALSE
> : @ 1332491447 backlight is_off
> : @ 1332491447 snoozing: until_dim 7200 30 75
> : @ 1332491447 until-sleep_type is until_dim-soft
> rtcwake: wakeup from "mem" using /dev/rtc0 at Fri Mar 23 08:31:22 2012
>
> #### End pre-suspended ####
>
> However once suspended and a 'wlanpacket' wakeup is generated there is a
> difference in the logging, 'network busy' doesn't prevent the next
> suspend from occurring:
>
> #### Start post-suspend ####
>
> rtcwake: wakeup from "mem" using /dev/rtc0 at Fri Mar 23 08:31:22 2012
>
> : @ 1332491451 got wakeup: wlanpacket @ 1332491451, slept 3
> : @ 1332491451 until-sleep_type is until_dim-soft
> : @ 1332491453 network busy
> rtcwake: wakeup from "mem" using /dev/rtc0 at Fri Mar 23 08:31:24 2012
>
> : @ 1332491458 got wakeup: wlanpacket @ 1332491458, slept 5
> : @ 1332491459 until-sleep_type is until_dim-soft
> : @ 1332491461 network busy
> rtcwake: wakeup from "mem" using /dev/rtc0 at Fri Mar 23 08:31:26 2012
>
> : @ 1332491465 got wakeup: wlanpacket @ 1332491465, slept 4
> : @ 1332491466 until-sleep_type is until_dim-soft
> : @ 1332491467 network busy
> rtcwake: wakeup from "mem" using /dev/rtc0 at Fri Mar 23 08:31:29 2012
>
> : @ 1332491472 got wakeup: wlanpacket @ 1332491472, slept 5
> : @ 1332491473 until-sleep_type is until_dim-soft
> : @ 1332491477 network busy
> rtcwake: wakeup from "mem" using /dev/rtc0 at Fri Mar 23 08:31:31 2012
>
> : @ 1332491482 got wakeup: wlanpacket @ 1332491482, slept 5
> : @ 1332491482 until-sleep_type is until_dim-soft
> : @ 1332491484 network busy
> rtcwake: wakeup from "mem" using /dev/rtc0 at Fri Mar 23 08:31:33 2012
>
>
> #### End post-suspend ####
>
> 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.
>
>
> > please point me to your release repo for powerd. i'd like to get back
> > to understanding the problem reported by the testing group.
> >
>
> Problem resolved as of March 24 round of testing.
okay.
paul
=---------------------
paul fox, pgf at laptop.org
More information about the OLPC-NZ
mailing list