11.3.1 build 13 released for XO-1.75

[Paul Fox]

john wrote:
 > 
 > It turns out not to be so simple.  I had two laptops stop
 > suspending after running for over 2K cycles.  They weren't hung ---
 > Linux thought it was suspending/resuming --- but the EC indicated
 > that they were never actually suspending.  Stopping my script and
 > restarting it (with the standalone rtcwake at the start) caused the
 > laptop to restart suspending.

did you note the console messages?  i'm interested in whether the
symptom is the same as i was seeing earlier.  in particular, note
whether it says "Freezing of tasks aborted...", because that implies
there's a wakeup pending.

given the nature of the failure we were seeing (and that i'm guessing
you saw above), for now i'd eliminate the inner race-stopping loop i
suggested this evening.  increase the suspend time to reduce the
likelihood of the alarm firing before suspend occurs.  at least that
way if something bad happens it'll stop.  (and if it does stop, make
note of the console messages.)

 > I'm not sure I can believe test results w. os13...

well, the further we get, the more bugs we'll flush out of hiding. 
think of it as a good thing!! ;-)

happy thanksgiving, all!

paul

 > 
 > Cheers,
 > wad
 > 
 > On Nov 23, 2011, at 6:30 PM, Martin Langhoff wrote:
 > 
 > > So the question is -- what's different about the first S/R cyce. And one 
 > obvious (naive?) answer is:  it is killing USB.
 > > 
 > > Subsequent S/R cycles, perhaps benefit from a faster / different S/R codepath 
 > that doesn't have to deal with USB.
 > > 
 > > cheers,
 > > 
 > > 
 > > m
 > > { Martin Langhoff - one laptop per child }
 > > 
 > > On Nov 23, 2011 5:22 PM, "John Watlington" <wad at laptop.org> wrote:
 > > 
 > > On Nov 23, 2011, at 4:00 PM, Paul Fox wrote:
 > > 
 > > > john wrote:
 > > >> I also ran into the problem that suspends take longer than on
 > > >> earlier OSs.   Frequently a three second wakeup has passed
 > > >> before suspend completes.  Even a six second wakeup hangs
 > > >> occasionally.   I added pgf's code to tell the kernel to abort a
 > > >> suspend if a wakeup event has happened during the
 > > >> suspend operation to my script, and it fixed the problem.
 > > >>
 > > >> I then ran into the problem that os13 doesn't actually
 > > >> suspend.   This appears to be related to EC code --- if it hasn't
 > > >> updated the EC code it works fine.    Linux thinks it is suspending,
 > > >> but the power light never blinks.   Also seems to relate to having
 > > >> DC power provided.
 > > >
 > > > i think that EC thing may have been a red herring.
 > > >
 > > > it seems that the "pgf's code" you added may be the culprit. (i.e.,
 > > > the code from http://dev.laptop.org/ticket/11416#comment:3)  i don't
 > > > know what's going on, but if i run, or rerun, your script on a failing
 > > > machine, i reliably get errors to the effect of "processes refuse to
 > > > freeze after 0.00 seconds" (from memory).  if i run just a single
 > > > rtcwake (timeout doesn't matter) _outside_ of your dortc script, that
 > > > s/r works, and then i can start your script and it, too, works.  since
 > > > powerd will do an rtcwake on its own if you don't kill it soon enough,
 > > > some of your "successful" runs may have benefitted from that.
 > > >
 > > > so i have your entire testbed running now, mostly using that trick.  i
 > > > did not have to set olpc-ols.0/high_lim to zero.
 > > 
 > > 
 > > Thanks.  I've modified my script to call rtcwake once w. a long
 > > wakeup, then to move into the fast cycle with the kernel aborting
 > > suspend if the wakeup event overtakes it during suspend.
 > > 
 > > wad
 > > 
 > > _______________________________________________
 > > Devel mailing list
 > > Devel at lists.laptop.org
 > > http://lists.laptop.org/listinfo/devel

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