re active the network mesh when suspends the system

[Paul Fox]

martin wrote:
 > I have done a few test in 3 different builds, the tests are:
 > 
 > A. Killing the mesh with "echo 0 > /sys/class/net/eth0/lbs_mesh", then
 > suspend and then check if the mesh is re-activated after resume.
 > B. While the mesh is active, add a script in postresume.d with the same line
 > to kill the mesh (granting it run permission), then suspend and then check
 > if the mesh is de-activated after resume.
 > 
 > The builds I used for the test are:
 > 
 > * olpc os852 (powerd 26, kernel 2.6.31_xo1.20100823.1641.1.olpc)
 > * olpc os359 (powerd 32, kernel 2.6.31_xo1-20101119.1249.1.olpc)
 > * last dextrose 2 (powerd 32, kernel 2.6.31_xo1-20101216.1250.1.olpc)
 > 
 > Results:
 > 
 > For build os582:
 > A: the mesh is _not_ being re-activated (this is the behaviour we need!)
 > B: postresume.d scripts are not supported. (but if does not matter because
 > with A is enough)

there was a bug in os852 which prevented us from ever powering off
the wlan during suspend.  it was as if config_MESH_DURING_SUSPEND was
always turned on.

have your script sleep for 10 or 20 seconds before disabling mesh, and
see if that helps.  there may be a better solution, but that would give
some more data.

paul

 > 
 > For build os359:
 > A: the mesh is re-activated. :(
 > B: the mesh is not being de-activated (even though the script effectively
 > runs, something else must be happening _after_ postresume.d script that
 > re-activates the mesh)
 > 
 > For build last dextrose 2:
 > A: the mesh is re-activated. :(
 > B: the mesh is not being de-activated (it is probably the same problem as
 > with os359)
 > 
 > Comments:
 > 
 > I am not sure why the os852 build behaves as we need, while any of the
 > newest builds does not. Could it be a regression in powerd?

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