[Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

[Martin Abente]

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,
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/devel/attachments/20120502/9947a326/attachment.html>