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)
On Wed, May 2, 2012 at 5:21 AM, Jon Nettleton <jon.nettle...@gmail.com>wrote: > On Wed, May 2, 2012 at 10:42 AM, Martin Langhoff > <martin.langh...@gmail.com> wrote: > > On Wed, May 2, 2012 at 4:07 AM, Martin Abente > > <martin.abente.lah...@gmail.com> 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. > > 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 >
_______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
