Hi,
Can anyone with a 4.10.x kernel run "iw reg get" to
verified it?
I get with different wireless devices and platforms:
global
country 00: DFS-UNSET
(2402 - 2472 @ 40), (6, 20), (N/A)
(2457 - 2482 @ 20), (6, 20), (N/A), AUTO-BW, PASSIVE-SCAN
(2474 - 2494 @ 20), (6, 20), (N/A), NO-OFDM, PASSIVE-SCAN
(5170 - 5250 @ 80), (6, 20), (N/A), AUTO-BW, PASSIVE-SCAN
(5250 - 5330 @ 80), (6, 20), (0 ms), DFS, AUTO-BW, PASSIVE-SCAN
(5490 - 5730 @ 160), (6, 20), (0 ms), DFS, PASSIVE-SCAN
(5735 - 5835 @ 80), (6, 20), (N/A), PASSIVE-SCAN
(57240 - 63720 @ 2160), (N/A, 0), (N/A)
It works flawlessly with 4.9.13:
global
country ES: DFS-ETSI
(2400 - 2483 @ 40), (N/A, 20), (N/A)
(5150 - 5250 @ 80), (N/A, 23), (N/A), NO-OUTDOOR, AUTO-BW
(5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS, AUTO-BW
(5470 - 5725 @ 160), (N/A, 26), (0 ms), DFS
(57000 - 66000 @ 2160), (N/A, 40), (N/A)
phy#0
country AW: DFS-ETSI
(2402 - 2482 @ 40), (N/A, 20), (N/A)
(5170 - 5250 @ 80), (N/A, 20), (N/A), AUTO-BW
(5250 - 5330 @ 80), (N/A, 20), (0 ms), DFS, AUTO-BW
(5490 - 5710 @ 160), (N/A, 27), (0 ms), DFS
Thank you.
On 03/18/2017 02:45 PM, Johannes Berg wrote:
> On Sat, 2017-03-18 at 12:41 -0500, Larry Finger wrote:
>>
>> I have duplicated your bug and I have bisected it to
>>
>> commit 2ae0f17df1cd52aafd1ab0415ea1f1dd56dc0e2a
>> Author: Johannes Berg <[email protected]>
>> Date: Mon Oct 24 14:40:04 2016 +0200
>>
>> genetlink: use idr to track families
>>
>> This patch is quite extensive and I have no idea which part is
>> failing, thus all I can do is report this confirmation.
>
> I don't think that makes any sense - have you verified that reverting
> that makes it go away?
Due to conflicts, I cannot simply revert it; however if I check out the previous
commit 489111e5c25b93be80340c3113d71903d7c82136 ("genetlink: statically
initialize families"), then the kernel is OK.
Larry
On 03/21/2017 06:43 AM, Kalle Valo wrote:
> Larry Finger <[email protected]> writes:
>
>> On 03/18/2017 02:45 PM, Johannes Berg wrote:
>>> On Sat, 2017-03-18 at 12:41 -0500, Larry Finger wrote:
>>>>
>>>> I have duplicated your bug and I have bisected it to
>>>>
>>>> commit 2ae0f17df1cd52aafd1ab0415ea1f1dd56dc0e2a
>>>> Author: Johannes Berg <[email protected]>
>>>> Date: Mon Oct 24 14:40:04 2016 +0200
>>>>
>>>> genetlink: use idr to track families
>>>>
>>>> This patch is quite extensive and I have no idea which part is
>>>> failing, thus all I can do is report this confirmation.
>>>
>>> I don't think that makes any sense - have you verified that reverting
>>> that makes it go away?
>>
>> Something is wrong with my wireless-testing-next tree. I just built
>> the mainline 4.11-rc3, and it does not have the problem. I'm now sure
>> that the bisection was wrong.
>>
>> I will need to refresh w-d-n and try again.
>
> Do you mean wireless-drivers-next or wireless-testing? If the latter,
> please note that you cannot really bisect anything on wireless-testing
> because it's rebased every time. wireless-drivers-next should be safe to
> use for bisection because I don't rebase that unless a major disaster
> happens, and IIRC that has not yet happened.
>
> (Well, in theory you can bisect wireless-testing but you have to be
> _really_ careful how to bisect and make sure that you follow the history
> correctly. Definitely not recommended.)
By w-d-n, I meant wireless-drivers-next. I have never done much with
wireless-testing since the change in maintainers. Thanks for the warning.
Larry
On 03/22/2017 10:15 AM, Stanislaw Gruszka wrote:
> On Sat, Mar 18, 2017 at 04:30:04PM -0500, Larry Finger wrote:
>> On 03/18/2017 02:45 PM, Johannes Berg wrote:
>>> On Sat, 2017-03-18 at 12:41 -0500, Larry Finger wrote:
>>>>
>>>> I have duplicated your bug and I have bisected it to
>>>>
>>>> commit 2ae0f17df1cd52aafd1ab0415ea1f1dd56dc0e2a
>>>> Author: Johannes Berg <[email protected]>
>>>> Date: Mon Oct 24 14:40:04 2016 +0200
>>>>
>>>> genetlink: use idr to track families
>>>>
>>>> This patch is quite extensive and I have no idea which part is
>>>> failing, thus all I can do is report this confirmation.
>>>
>>> I don't think that makes any sense - have you verified that reverting
>>> that makes it go away?
>>
>> Due to conflicts, I cannot simply revert it; however if I check out
>> the previous commit 489111e5c25b93be80340c3113d71903d7c82136
>> ("genetlink: statically initialize families"), then the kernel is
>> OK.
>
> I just posted a patch which most likely fixes this problem. I have some
> other issue on my setup, but seems this issue is also caused by the
> same bug in 2ae0f17df1cd52aafd1ab0415ea1f1dd56dc0e2a.
Stanislaw,
Your patch does fix this problem. Thanks.
Larry
On 03/14/2017 08:14 PM, Xose Vazquez Perez wrote:
> Hi,
>
> Can anyone with a 4.10.x kernel run "iw reg get" to
> verified it?
>
> I get with different wireless devices and platforms:
> global
> country 00: DFS-UNSET
> (2402 - 2472 @ 40), (6, 20), (N/A)
> (2457 - 2482 @ 20), (6, 20), (N/A), AUTO-BW, PASSIVE-SCAN
> (2474 - 2494 @ 20), (6, 20), (N/A), NO-OFDM, PASSIVE-SCAN
> (5170 - 5250 @ 80), (6, 20), (N/A), AUTO-BW, PASSIVE-SCAN
> (5250 - 5330 @ 80), (6, 20), (0 ms), DFS, AUTO-BW, PASSIVE-SCAN
> (5490 - 5730 @ 160), (6, 20), (0 ms), DFS, PASSIVE-SCAN
> (5735 - 5835 @ 80), (6, 20), (N/A), PASSIVE-SCAN
> (57240 - 63720 @ 2160), (N/A, 0), (N/A)
>
>
> It works flawlessly with 4.9.13:
> global
> country ES: DFS-ETSI
> (2400 - 2483 @ 40), (N/A, 20), (N/A)
> (5150 - 5250 @ 80), (N/A, 23), (N/A), NO-OUTDOOR, AUTO-BW
> (5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS, AUTO-BW
> (5470 - 5725 @ 160), (N/A, 26), (0 ms), DFS
> (57000 - 66000 @ 2160), (N/A, 40), (N/A)
>
> phy#0
> country AW: DFS-ETSI
> (2402 - 2482 @ 40), (N/A, 20), (N/A)
> (5170 - 5250 @ 80), (N/A, 20), (N/A), AUTO-BW
> (5250 - 5330 @ 80), (N/A, 20), (0 ms), DFS, AUTO-BW
> (5490 - 5710 @ 160), (N/A, 27), (0 ms), DFS
I have duplicated your bug and I have bisected it to
commit 2ae0f17df1cd52aafd1ab0415ea1f1dd56dc0e2a
Author: Johannes Berg <[email protected]>
Date: Mon Oct 24 14:40:04 2016 +0200
genetlink: use idr to track families
This patch is quite extensive and I have no idea which part is failing, thus all
I can do is report this confirmation.
Larry
On Sat, Mar 18, 2017 at 04:30:04PM -0500, Larry Finger wrote:
> On 03/18/2017 02:45 PM, Johannes Berg wrote:
> >On Sat, 2017-03-18 at 12:41 -0500, Larry Finger wrote:
> >>
> >>I have duplicated your bug and I have bisected it to
> >>
> >>commit 2ae0f17df1cd52aafd1ab0415ea1f1dd56dc0e2a
> >>Author: Johannes Berg <[email protected]>
> >>Date: Mon Oct 24 14:40:04 2016 +0200
> >>
> >> genetlink: use idr to track families
> >>
> >>This patch is quite extensive and I have no idea which part is
> >>failing, thus all I can do is report this confirmation.
> >
> >I don't think that makes any sense - have you verified that reverting
> >that makes it go away?
>
> Due to conflicts, I cannot simply revert it; however if I check out
> the previous commit 489111e5c25b93be80340c3113d71903d7c82136
> ("genetlink: statically initialize families"), then the kernel is
> OK.
I just posted a patch which most likely fixes this problem. I have some
other issue on my setup, but seems this issue is also caused by the
same bug in 2ae0f17df1cd52aafd1ab0415ea1f1dd56dc0e2a.
Stanislaw
On 03/18/2017 02:45 PM, Johannes Berg wrote:
> On Sat, 2017-03-18 at 12:41 -0500, Larry Finger wrote:
>>
>> I have duplicated your bug and I have bisected it to
>>
>> commit 2ae0f17df1cd52aafd1ab0415ea1f1dd56dc0e2a
>> Author: Johannes Berg <[email protected]>
>> Date: Mon Oct 24 14:40:04 2016 +0200
>>
>> genetlink: use idr to track families
>>
>> This patch is quite extensive and I have no idea which part is
>> failing, thus all I can do is report this confirmation.
>
> I don't think that makes any sense - have you verified that reverting
> that makes it go away?
Something is wrong with my wireless-testing-next tree. I just built the mainline
4.11-rc3, and it does not have the problem. I'm now sure that the bisection was
wrong.
I will need to refresh w-d-n and try again.
Larry
On Sat, 2017-03-18 at 12:41 -0500, Larry Finger wrote:
>
> I have duplicated your bug and I have bisected it to
>
> commit 2ae0f17df1cd52aafd1ab0415ea1f1dd56dc0e2a
> Author: Johannes Berg <[email protected]>
> Date: Mon Oct 24 14:40:04 2016 +0200
>
> genetlink: use idr to track families
>
> This patch is quite extensive and I have no idea which part is
> failing, thus all I can do is report this confirmation.
I don't think that makes any sense - have you verified that reverting
that makes it go away?
johannes
Larry Finger <[email protected]> writes:
> On 03/18/2017 02:45 PM, Johannes Berg wrote:
>> On Sat, 2017-03-18 at 12:41 -0500, Larry Finger wrote:
>>>
>>> I have duplicated your bug and I have bisected it to
>>>
>>> commit 2ae0f17df1cd52aafd1ab0415ea1f1dd56dc0e2a
>>> Author: Johannes Berg <[email protected]>
>>> Date: Mon Oct 24 14:40:04 2016 +0200
>>>
>>> genetlink: use idr to track families
>>>
>>> This patch is quite extensive and I have no idea which part is
>>> failing, thus all I can do is report this confirmation.
>>
>> I don't think that makes any sense - have you verified that reverting
>> that makes it go away?
>
> Something is wrong with my wireless-testing-next tree. I just built
> the mainline 4.11-rc3, and it does not have the problem. I'm now sure
> that the bisection was wrong.
>
> I will need to refresh w-d-n and try again.
Do you mean wireless-drivers-next or wireless-testing? If the latter,
please note that you cannot really bisect anything on wireless-testing
because it's rebased every time. wireless-drivers-next should be safe to
use for bisection because I don't rebase that unless a major disaster
happens, and IIRC that has not yet happened.
(Well, in theory you can bisect wireless-testing but you have to be
_really_ careful how to bisect and make sure that you follow the history
correctly. Definitely not recommended.)
--
Kalle Valo