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