[Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend
martin.abente.lahaye at gmail.com
Wed May 2 05:31:47 EDT 2012
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.nettleton at gmail.com>wrote:
> On Wed, May 2, 2012 at 10:42 AM, Martin Langhoff
> <martin.langhoff at gmail.com> wrote:
> > On Wed, May 2, 2012 at 4:07 AM, Martin Abente
> > <martin.abente.lahaye at gmail.com> wrote:
> >> I think (guessing by the responses) the original problem here is that,
> >> 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
> >> 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
> >> 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
> I just played around with the udev script and there definitely seems
> to be some timing issues even with that.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Sugar-devel