I didn't see patches from open80211s project for a while, which means it will break as the rest mac80211/drivers are evolving quickly.
to get mesh working I now spend more time to use the ibss/ad-hoc mode in mac80211 instead.
xxiao
--- On Tue, 8/4/09, Steve Glass <[email protected]> wrote:
> From: Steve Glass <[email protected]>
> Subject: Status of 802.11s in wireless-testing?
> To: [email protected]
> Date: Tuesday, August 4, 2009, 11:45 PM
> Hi,
>
> I noticed today that 802.11s has been disabled when running
> "make xconfig". Apparently its been marked as
> broken although Luis Rodriguez has posted a patch to at
> least have it compile successfully.
>
>
> I missed all this because I usually run "make
> oldconfig" so it came as a surprise . It did, however,
> explain why iw was telling me that my ath5k device supported
> mesh point mode but would fail when I tried to create one.
>
>
> What can we do to help? Its a huge step backwards to be
> marked as broken so I've applied Luis' compilation
> patch and want to know where to look to find out what
> functionality is broken. Is anyone working on it? What can
> we do to help?
>
>
> Stevie
>
> --
> The highest human happiness is not the exploitation of the
> present but the preparation of the future.
>
>
> -----Inline Attachment Follows-----
>
> _______________________________________________
> Devel mailing list
> [email protected]
> http://open80211s.com/mailman/listinfo/devel
>
Hi Johannes,
On Wed, Aug 5, 2009 at 10:04 AM, Johannes Berg<[email protected]> wrote:
> Right now, except from the stuff Luis had broken and fixed, the real
> problem is that there are a bunch of bugs that appear to have been in
> the code forever, just never noticed -- for instance the code can end up
> calling synchronize_rcu() in an atomic section.
I agree that there is a bug in that would cause a synchronize_rcu() in
an atomic section when the mpath table grows beyond a certain size.
The bug was there since the first submission of the mesh code, yes.
However, the "bunch of bugs that appear to have been in the code
forever" are, I believe, regressions. In particular we've identified:
- Airtime Link Metric broken (fix in progress)
- Forwarding path broken (fixed here:
http://marc.info/?l=linux-wireless&m=124698982910794&w=2)
- mpath pending queue broken (fixed here:
http://marc.info/?l=linux-wireless&m=124717648406661&w=2)
- PREQ notification broken (fixed here:
http://marc.info/?l=linux-wireless&m=124752948320455&w=2)
We've been busy with those but the synchronize_rcu fix is next in our list.
> This is the reason for disabling it -- it can splatter all over the
> scheduler if that happens, and it's not clear to me that it cannot
> happen. It seems not to happen in _most_ scenarios, but I've certainly
> caused it to happen by not beaconing, for instance.
I also agree with your assessment of the severity of the bug.
Hopefully we'll get to fix it really soon so we can re-enable mesh
again.
Thanks,
On Wed, Aug 05, 2009 at 09:08:54AM -0700, xxiao wrote:
> I didn't see patches from open80211s project for a while, which
> means it will break as the rest mac80211/drivers are evolving quickly.
You may be right, but it _should_not_ mean that -- at least not
necessarily. Yes, there will be accidental breakage from time to time.
But developers ought to keep mesh in mind when making changes and
they should be "on the hook" to fix whatever breaks.
John
--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.
?Viva Honduras Libre!
On Wed, 2009-08-05 at 12:50 -0400, John W. Linville wrote:
> On Wed, Aug 05, 2009 at 09:08:54AM -0700, xxiao wrote:
> > I didn't see patches from open80211s project for a while, which
> > means it will break as the rest mac80211/drivers are evolving quickly.
>
> You may be right, but it _should_not_ mean that -- at least not
> necessarily. Yes, there will be accidental breakage from time to time.
> But developers ought to keep mesh in mind when making changes and
> they should be "on the hook" to fix whatever breaks.
Right now, except from the stuff Luis had broken and fixed, the real
problem is that there are a bunch of bugs that appear to have been in
the code forever, just never noticed -- for instance the code can end up
calling synchronize_rcu() in an atomic section.
This is the reason for disabling it -- it can splatter all over the
scheduler if that happens, and it's not clear to me that it cannot
happen. It seems not to happen in _most_ scenarios, but I've certainly
caused it to happen by not beaconing, for instance.
johannes
Hi Javier,
> I agree that there is a bug in that would cause a synchronize_rcu() in
> an atomic section when the mpath table grows beyond a certain size.
> The bug was there since the first submission of the mesh code, yes.
>
> However, the "bunch of bugs that appear to have been in the code
> forever" are, I believe, regressions. In particular we've identified:
> - Airtime Link Metric broken (fix in progress)
> - Forwarding path broken (fixed here:
> http://marc.info/?l=linux-wireless&m=124698982910794&w=2)
> - mpath pending queue broken (fixed here:
> http://marc.info/?l=linux-wireless&m=124717648406661&w=2)
> - PREQ notification broken (fixed here:
> http://marc.info/?l=linux-wireless&m=124752948320455&w=2)
>
> We've been busy with those but the synchronize_rcu fix is next in our list.
I was really only referring to the issue with synchronize_rcu(), and the
two related things where there's GFP_KERNEL that should be GFP_ATOMIC,
although that might have been fixed? It just felt like multiple
issues/places to me that could run into this.
> I also agree with your assessment of the severity of the bug.
> Hopefully we'll get to fix it really soon so we can re-enable mesh
> again.
Yes, that would be great, thanks. I've been meaning to look into this
(if only to understand the mesh code better), but I have little time and
a lot of other things to fix that are still regressions (currently
looking at assoc vs. reassoc for instance).
johannes