[BUG] with a 4.10.x kernel it's impossible to apply country regulatory rules

[BUG] with a 4.10.x kernel it's impossible to apply country regulatory rules

[Xose Vazquez Perez]

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.

Re: [BUG] with a 4.10.x kernel it's impossible to apply country regulatory rules

[Larry Finger]

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 <johannes.berg@intel.com>
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

Re: [BUG] with a 4.10.x kernel it's impossible to apply country regulatory rules

[Johannes Berg]

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 <johannes.berg@intel.com>
> 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

Re: [BUG] with a 4.10.x kernel it's impossible to apply country regulatory rules

[Larry Finger]

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 <johannes.berg@intel.com>
>> 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

Re: [BUG] with a 4.10.x kernel it's impossible to apply country regulatory rules

[Stanislaw Gruszka]

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 <johannes.berg@intel.com>
> >>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

Re: [BUG] with a 4.10.x kernel it's impossible to apply country regulatory rules

[Larry Finger]

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 <johannes.berg@intel.com>
>>>> 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

Re: [BUG] with a 4.10.x kernel it's impossible to apply country regulatory rules

[Larry Finger]

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 <johannes.berg@intel.com>
>> 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

Re: [BUG] with a 4.10.x kernel it's impossible to apply country regulatory rules

[Kalle Valo]

Larry Finger <Larry.Finger@lwfinger.net> 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 <johannes.berg@intel.com>
>>> 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

Re: [BUG] with a 4.10.x kernel it's impossible to apply country regulatory rules

[Larry Finger]

On 03/21/2017 06:43 AM, Kalle Valo wrote:
> Larry Finger <Larry.Finger@lwfinger.net> 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 <johannes.berg@intel.com>
>>>> 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