How hard and sensible do you think it could be to backport that patch? :D (Assuming that touching the kernel is an option for someone, hehe) <div class="gmail_quote">On Wed, May 2, 2012 at 5:21 AM, Jon Nettleton <<a href="mailto:jon.nettleton@gmail.com" target="_blank">jon.nettleton@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Wed, May 2, 2012 at 10:42 AM, Martin Langhoff <<a href="mailto:martin.langhoff@gmail.com">martin.langhoff@gmail.com</a>> wrote: > On Wed, May 2, 2012 at 4:07 AM, Martin Abente > <<a href="mailto:martin.abente.lahaye@gmail.com">martin.abente.lahaye@gmail.com</a>> wrote: >> I think (guessing by the responses) the original problem here is that, if >> you disable the mesh AFTER NM has taken the device, NM crashes. This a >> regression bug, considering that this didn't happened in fedora-11 based >> builds. > > The timings in F11 builds were completely different. Maybe you were > winning the race that you're now losing. > >> So the solution here is to find another place to place the script, where it >> guarantee that the script will be executed before NM does its job at resume >> time. > > udev script :-) -- I am pretty sure you can number yourself lower (to > run earlier) than the udev script that fires off the "new device" > event to NM. > >> Another solution is to find out why NM crashes now and why didn't before, >> but I wouldn't go that way. > > Making NM completely resilient to these race conditions is probably a hard task. </div>This is also a temporary solution. There is a kernel patch in 3.1 and greater kernels that allows you to disable mesh as a kernel module parameter. I just played around with the udev script and there definitely seems to be some timing issues even with that. -Jon </blockquote></div>