Chris,<br><br>It happened two times during an scp tranfer between two XOs (I don't recall if they were transferring via eth0 or via msh0 by the time - it is a test that continuously switches the interfaces). It did not recover (I waited a couple of minutes), until I brought the XO back, hitting the touch pad. It them resumed the scp transfer. 
<br><br>It is not easy to reproduce this effect with the above test. How can we reduce the time for the automatic suspend to happen? (Sorry couldn't find this in the wiki).<br><br>[Ok. Maybe automatic and manual suspend would be more intuitive. ;-)]
<br><br><div class="gmail_quote">On Jan 16, 2008 4:10 PM, Chris Ball <<a href="mailto:cjb@laptop.org">cjb@laptop.org</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi,<br><div class="Ih2E3d"><br>   > If you, for example, are transfering a file when the XO enters in<br>   > power savings mode, the transfer will halt.<br><br></div>For how long?  As soon as the XO hits suspend, the WLAN/EC will
<br>assert wakeup on receipt of the next unicast packet, and then OHM<br>will wait another thirty seconds or more before suspending again.<br>Have you experienced otherwise?  The transfer should continue after<br>the wakeup without any disconnection.
<br><div class="Ih2E3d"><br>   > (I avoided using the term 'suspend'. I believe suspend is an user<br>   > action, while sleep is automatic, anyway...)<br><br></div>Other way around; suspend is automatic and frequent, sleep is
<br>user-invoked.<br><div class="Ih2E3d"><br>   > I don't believe this is a feature. How should we deal with it?<br><br></div>As above, I think this should be harmless.  If you disagree, as the<br>olpc-update script does, you can "touch/rm /etc/ohm/inhibit-suspend"
<br>before/after a transfer.<br><br>Note that if the transfer uses non-trivial CPU (for example, rsync)<br>it should inhibit suspend automatically by virtue of the CPU use.<br><br>- Chris.<br><font color="#888888">--<br>Chris Ball   <
<a href="mailto:cjb@laptop.org">cjb@laptop.org</a>><br></font></blockquote></div><br>