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, p...@laptop.org _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel