Hi, this is your Linux kernel regression tracker.
Luca, I noticed a regression report in bugzilla where I'd like your
advice on. To quote https://bugzilla.kernel.org/show_bug.cgi?id=216753
> It looks like the self-managed regulatory information is causing the 6ghz band to be disabled on my AX211 (in the US).
> iw reg get shows no 6ghz bands (output at the bottom).
>
> $ sudo iw phy0 channel
> ...
> Band 4:
> * 5955 MHz [1] (disabled)
> * 5975 MHz [5] (disabled)
> * 5995 MHz [9] (disabled)
> ....(continues with all disabled
> * 7115 MHz [233] (disabled)
> ...
>
> I was able to narrow this down to having been introduced during the 5.16 development window, as 5.15.79 linux-stable kernel works and the 5.16.12 does
> not (earlier builds of 5.16 kernel fail to boot on my machine for some reason).
>
> I found https://community.frame.work/t/kernel-5-16-6ghz-disabled-ax210/15675/5
> and they imply that this regression was introduced by
> 698b166ed3464e1604a0e6a3e23cc1b529a5adc1
> I haven't independently verified this commit as the definitive issue.
You authored 698b166ed346 ("iwlwifi: mvm: read 6E enablement flags from
DSM and pass to FW"). As it is a regressions is ideally should be dealt
with. But this area in tricky due to the legal implications. Hence I
wonder: is there anything we can do about this, or is this simply a case
where we have to bite the bullet and live with this regression?
Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
P.S.: As the Linux kernel's regression tracker I deal with a lot of
reports and sometimes miss something important when writing mails like
this. If that's the case here, don't hesitate to tell me in a public
reply, it's in everyone's interest to set the public record straight.
On Thu, 2022-12-01 at 11:14 +0100, Thorsten Leemhuis wrote:
> Hi, this is your Linux kernel regression tracker.
>
> Luca, I noticed a regression report in bugzilla where I'd like your
> advice on. To quote https://bugzilla.kernel.org/show_bug.cgi?id=216753
Hi Thorsten wearing-the-regression-hat, ????
I'm not the maintainer of iwlwifi anymore, so I'm adding the new
maintainer here, Gregory Greenman.
Gregory, can you take a look?
> > It looks like the self-managed regulatory information is causing the 6ghz band to be disabled on my AX211 (in the US).
> > iw reg get shows no 6ghz bands (output at the bottom).
> >
> > $ sudo iw phy0 channel
> > ...
> > Band 4:
> > * 5955 MHz [1] (disabled)
> > * 5975 MHz [5] (disabled)
> > * 5995 MHz [9] (disabled)
> > ....(continues with all disabled
> > * 7115 MHz [233] (disabled)
> > ...
> >
> > I was able to narrow this down to having been introduced during the 5.16 development window, as 5.15.79 linux-stable kernel works and the 5.16.12 does
> > not (earlier builds of 5.16 kernel fail to boot on my machine for some reason).
> >
> > I found https://community.frame.work/t/kernel-5-16-6ghz-disabled-ax210/15675/5
> > and they imply that this regression was introduced by
> > 698b166ed3464e1604a0e6a3e23cc1b529a5adc1
> > I haven't independently verified this commit as the definitive issue.
>
> You authored 698b166ed346 ("iwlwifi: mvm: read 6E enablement flags from
> DSM and pass to FW"). As it is a regressions is ideally should be dealt
> with. But this area in tricky due to the legal implications. Hence I
> wonder: is there anything we can do about this, or is this simply a case
> where we have to bite the bullet and live with this regression?
>
> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
>
> P.S.: As the Linux kernel's regression tracker I deal with a lot of
> reports and sometimes miss something important when writing mails like
> this. If that's the case here, don't hesitate to tell me in a public
> reply, it's in everyone's interest to set the public record straight.
The other possibility is that this is actually a bios bug, as the DSM
is being read out of ACPI. In which case that would be Dell's fault.
Either way I appreciate any guidance you can provide.
Thanks,
Dave.
On Thu, Dec 1, 2022 at 5:33 AM Coelho, Luciano <[email protected]> wrote:
>
> On Thu, 2022-12-01 at 11:14 +0100, Thorsten Leemhuis wrote:
> > Hi, this is your Linux kernel regression tracker.
> >
> > Luca, I noticed a regression report in bugzilla where I'd like your
> > advice on. To quote https://bugzilla.kernel.org/show_bug.cgi?id=216753
>
> Hi Thorsten wearing-the-regression-hat, ????
>
> I'm not the maintainer of iwlwifi anymore, so I'm adding the new
> maintainer here, Gregory Greenman.
>
> Gregory, can you take a look?
>
>
> > > It looks like the self-managed regulatory information is causing the 6ghz band to be disabled on my AX211 (in the US).
> > > iw reg get shows no 6ghz bands (output at the bottom).
> > >
> > > $ sudo iw phy0 channel
> > > ...
> > > Band 4:
> > > * 5955 MHz [1] (disabled)
> > > * 5975 MHz [5] (disabled)
> > > * 5995 MHz [9] (disabled)
> > > ....(continues with all disabled
> > > * 7115 MHz [233] (disabled)
> > > ...
> > >
> > > I was able to narrow this down to having been introduced during the 5.16 development window, as 5.15.79 linux-stable kernel works and the 5.16.12 does
> > > not (earlier builds of 5.16 kernel fail to boot on my machine for some reason).
> > >
> > > I found https://community.frame.work/t/kernel-5-16-6ghz-disabled-ax210/15675/5
> > > and they imply that this regression was introduced by
> > > 698b166ed3464e1604a0e6a3e23cc1b529a5adc1
> > > I haven't independently verified this commit as the definitive issue.
> >
> > You authored 698b166ed346 ("iwlwifi: mvm: read 6E enablement flags from
> > DSM and pass to FW"). As it is a regressions is ideally should be dealt
> > with. But this area in tricky due to the legal implications. Hence I
> > wonder: is there anything we can do about this, or is this simply a case
> > where we have to bite the bullet and live with this regression?
> >
> > Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
> >
> > P.S.: As the Linux kernel's regression tracker I deal with a lot of
> > reports and sometimes miss something important when writing mails like
> > this. If that's the case here, don't hesitate to tell me in a public
> > reply, it's in everyone's interest to set the public record straight.
On 02.12.22 16:37, Dave Chiluk wrote:
> The other possibility is that this is actually a bios bug, as the DSM
> is being read out of ACPI. In which case that would be Dell's fault.
Yes and no, but no:
A kernel change exposed this problem, hence it doesn't matter if the
BIOS is faulty: it's makes it a kernel regression and those are not
allowed. For more on this see
https://docs.kernel.org/admin-guide/reporting-issues.html
That at least would be the normal approach. But the thing is: the legal
implications when it comes to things like wifi make this somewhat
trickier. :-/
> On Thu, Dec 1, 2022 at 5:33 AM Coelho, Luciano <[email protected]> wrote:
>>
>> On Thu, 2022-12-01 at 11:14 +0100, Thorsten Leemhuis wrote:
>>> Hi, this is your Linux kernel regression tracker.
>>>
>>> Luca, I noticed a regression report in bugzilla where I'd like your
>>> advice on. To quote https://bugzilla.kernel.org/show_bug.cgi?id=216753
>>
>> Hi Thorsten wearing-the-regression-hat, ????
:-D
>> I'm not the maintainer of iwlwifi anymore, so I'm adding the new
>> maintainer here, Gregory Greenman.
Well, you where the author of the commit, that's why I addressed you.
But if Gregory or someone else steps in that's of course totally fine
for me as well. :-D
Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
P.S.: As the Linux kernel's regression tracker I deal with a lot of
reports and sometimes miss something important when writing mails like
this. If that's the case here, don't hesitate to tell me in a public
reply, it's in everyone's interest to set the public record straight.
>> Gregory, can you take a look?
>>
>>
>>>> It looks like the self-managed regulatory information is causing the 6ghz band to be disabled on my AX211 (in the US).
>>>> iw reg get shows no 6ghz bands (output at the bottom).
>>>>
>>>> $ sudo iw phy0 channel
>>>> ...
>>>> Band 4:
>>>> * 5955 MHz [1] (disabled)
>>>> * 5975 MHz [5] (disabled)
>>>> * 5995 MHz [9] (disabled)
>>>> ....(continues with all disabled
>>>> * 7115 MHz [233] (disabled)
>>>> ...
>>>>
>>>> I was able to narrow this down to having been introduced during the 5.16 development window, as 5.15.79 linux-stable kernel works and the 5.16.12 does
>>>> not (earlier builds of 5.16 kernel fail to boot on my machine for some reason).
>>>>
>>>> I found https://community.frame.work/t/kernel-5-16-6ghz-disabled-ax210/15675/5
>>>> and they imply that this regression was introduced by
>>>> 698b166ed3464e1604a0e6a3e23cc1b529a5adc1
>>>> I haven't independently verified this commit as the definitive issue.
>>>
>>> You authored 698b166ed346 ("iwlwifi: mvm: read 6E enablement flags from
>>> DSM and pass to FW"). As it is a regressions is ideally should be dealt
>>> with. But this area in tricky due to the legal implications. Hence I
>>> wonder: is there anything we can do about this, or is this simply a case
>>> where we have to bite the bullet and live with this regression?
>>>
>>> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
>>>
>>> P.S.: As the Linux kernel's regression tracker I deal with a lot of
>>> reports and sometimes miss something important when writing mails like
>>> this. If that's the case here, don't hesitate to tell me in a public
>>> reply, it's in everyone's interest to set the public record straight.
>
>
Hi Thorsten,
>> The other possibility is that this is actually a bios bug, as the DSM
>> is being read out of ACPI. In which case that would be Dell's fault.
>
> Yes and no, but no:
>
> A kernel change exposed this problem, hence it doesn't matter if the
> BIOS is faulty: it's makes it a kernel regression and those are not
> allowed. For more on this see
> https://docs.kernel.org/admin-guide/reporting-issues.html
>
> That at least would be the normal approach. But the thing is: the legal
> implications when it comes to things like wifi make this somewhat
> trickier. :-/
so you need to set your country code first before any of the regulatory
enabled channels on 6Ghz get used. Otherwise you are stuck in the world
domain that doesn’t allow 6Ghz at all.
Two choices, either you run iwd and just set Country=DE where this than
would be persistent; see iwd.config(5). Or you do this via iw reg set DE
manually. wpa_supplicant has a set_country wrapper, but I don’t see it
being used anywhere, so I assume you have to do this manually when using
wpa_supplicant.
And of course tools like crda etc. need to be fully functional to load
the appropriate regulatory information. Since any 6Ghz operation is
blocked by default.
Regards
Marcel
Running
$ iw reg set US
or
$ iw reg set DE
do not result in the bands becoming enabled. I should have included
that in the initial bug report. Additionally shouldn't the country
code should be getting gathered through 802.11d from the broadcast APs
within region?
Also crda is now disabled in both debian and Ubuntu.
https://bugs.debian.org/1003903
https://bugs.launchpad.net/ubuntu/jammy/+source/crda/+bug/1958918
I'm specifically on 22.04, and the 6ghz band works on the 5.15 ubuntu
kernel and the 5.15.79 linux-stable kernel.
The 6ghz band becomes disabled as soon as I upgrade to the 5.16+
linux-stable kernels. So from a user perspective this really is a case
of a kernel upgrade breaking user-space. This is what led me down
this rabbit hole here.
If there's something that needs to be done differently from a
userspace perspective I'm all ears, but this seems as if it's a hard
disable by the above mentioned commit.
Thanks,
On Fri, Dec 2, 2022 at 10:46 AM Marcel Holtmann <[email protected]> wrote:
>
> Hi Thorsten,
>
> >> The other possibility is that this is actually a bios bug, as the DSM
> >> is being read out of ACPI. In which case that would be Dell's fault.
> >
> > Yes and no, but no:
> >
> > A kernel change exposed this problem, hence it doesn't matter if the
> > BIOS is faulty: it's makes it a kernel regression and those are not
> > allowed. For more on this see
> > https://docs.kernel.org/admin-guide/reporting-issues.html
> >
> > That at least would be the normal approach. But the thing is: the legal
> > implications when it comes to things like wifi make this somewhat
> > trickier. :-/
>
> so you need to set your country code first before any of the regulatory
> enabled channels on 6Ghz get used. Otherwise you are stuck in the world
> domain that doesn’t allow 6Ghz at all.
>
> Two choices, either you run iwd and just set Country=DE where this than
> would be persistent; see iwd.config(5). Or you do this via iw reg set DE
> manually. wpa_supplicant has a set_country wrapper, but I don’t see it
> being used anywhere, so I assume you have to do this manually when using
> wpa_supplicant.
>
> And of course tools like crda etc. need to be fully functional to load
> the appropriate regulatory information. Since any 6Ghz operation is
> blocked by default.
>
> Regards
>
> Marcel
>
Hi Dave,
> Running
> $ iw reg set US
> or
> $ iw reg set DE
> do not result in the bands becoming enabled. I should have included
> that in the initial bug report. Additionally shouldn't the country
> code should be getting gathered through 802.11d from the broadcast APs
> within region?
>
> Also crda is now disabled in both debian and Ubuntu.
> https://bugs.debian.org/1003903
> https://bugs.launchpad.net/ubuntu/jammy/+source/crda/+bug/1958918
>
> I'm specifically on 22.04, and the 6ghz band works on the 5.15 ubuntu
> kernel and the 5.15.79 linux-stable kernel.
> The 6ghz band becomes disabled as soon as I upgrade to the 5.16+
> linux-stable kernels. So from a user perspective this really is a case
> of a kernel upgrade breaking user-space. This is what led me down
> this rabbit hole here.
>
> If there's something that needs to be done differently from a
> userspace perspective I'm all ears, but this seems as if it's a hard
> disable by the above mentioned commit.
can you run iwd and set Country=DE (or US) in its main.conf. I think
most distros have a 2.0 package of iwd available. With iwd we have
implemented all the handling and re-scanning to make sure we actually
get to use 6Ghz is available.
Btw. you can run iwd from its source tree. No need to install it if
You don’t want to mess up your system. Just make sure to disable
wpa_supplicant so it doesn’t interfere.
I have this working on 6.0 kernel (not with ax211 hardware though) and
it needed some help to get the regdom loaded correctly. I think the key
part was to install crda on Fedora.
$ iw reg get
global
country DE: 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
(5725 - 5875 @ 80), (N/A, 13), (N/A)
(5945 - 6425 @ 160), (N/A, 23), (N/A), NO-OUTDOOR
(57000 - 66000 @ 2160), (N/A, 40), (N/A)
Unless you see it available in iw reg get, then it is also not available,
but I remember that you also have per PHY regdom and other fun stuff. As
I said, it was a breath to get it running with iwd once you set your
country code in the config file.
On a note, you could run iwmon and see what nl80211 related calls to
regdom handling actually happen.
Regards
Marcel
On Fri, 2022-12-02 at 11:18 -0600, Dave Chiluk wrote:
Hello,
> The 6ghz band becomes disabled as soon as I upgrade to the 5.16+
> linux-stable kernels. So from a user perspective this really is a
> case of a kernel upgrade breaking user-space. This is what led me
> down this rabbit hole here.
FWIW
I have the same issue on a Lenovo T14 gen2 laptop with built-in ax210
card, and sold as Wifi-6E compliant.
The exact patch you mention causes the issue, so it seems my bios does
not return the correct values either.
I recompiled the kernel with all those cmd_allow_xxx bitmaps set to ~0
and 6Ghz works fine.
--
Maxime
On 02.12.22 18:42, Maxime Bizon wrote:
> On Fri, 2022-12-02 at 11:18 -0600, Dave Chiluk wrote:
>
>> The 6ghz band becomes disabled as soon as I upgrade to the 5.16+
>> linux-stable kernels. So from a user perspective this really is a
>> case of a kernel upgrade breaking user-space. This is what led me
>> down this rabbit hole here.
>
> FWIW
>
> I have the same issue on a Lenovo T14 gen2 laptop with built-in ax210
> card, and sold as Wifi-6E compliant.
>
> The exact patch you mention causes the issue, so it seems my bios does
> not return the correct values either.
That makes me (as a outsider that has no real knowledge about the inner
workings of the Linux Wifi subsystem) wonder: Does it work in Windows?
Because if that's the case I wonder how Windows ensures everything
confirms to regulatory requirements & standards. If that handled on the
software level if the info is missing in the firmware? Or is there a
another place in the firmware structures where Windows looks for details
(and we don't).
Or is that a Linux-only machine that might even use a different firmware?
Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
P.S.: As the Linux kernel's regression tracker I deal with a lot of
reports and sometimes miss something important when writing mails like
this. If that's the case here, don't hesitate to tell me in a public
reply, it's in everyone's interest to set the public record straight.
On Fri, Dec 2, 2022 at 11:46 AM Marcel Holtmann <[email protected]> wrote:
>
> Hi Dave,
>
> can you run iwd and set Country=DE (or US) in its main.conf. I think
> most distros have a 2.0 package of iwd available. With iwd we have
> implemented all the handling and re-scanning to make sure we actually
> get to use 6Ghz is available.
>
> Btw. you can run iwd from its source tree. No need to install it if
> You don’t want to mess up your system. Just make sure to disable
> wpa_supplicant so it doesn’t interfere.
@Marcel, I was able to build iwd from source, but was unable to get it
to run due to dbus namespace conflicts. I don't know enough about dbus
to debug that further. Running iwd from the archives (v1.26-3), and
setting COUNTRY=US in main.conf did not enable the 6e bands.
I don't think setting the global region is the issue, as iw reg set US
works fine, and results in the following iw reg get. Even before
$iw reg set US
phy#0 sets itself to the correct region. I think the issue is that
the bios, or the firmware blob being loaded by the ax211 that has some
bits improperly set that is causing the 6ghz to be disabled by the
kernel before userspace ever gets involved.
_________________snip_________________
$ sudo iw reg get
global
country US: DFS-FCC
(902 - 904 @ 2), (N/A, 30), (N/A)
(904 - 920 @ 16), (N/A, 30), (N/A)
(920 - 928 @ 8), (N/A, 30), (N/A)
(2400 - 2472 @ 40), (N/A, 30), (N/A)
(5150 - 5250 @ 80), (N/A, 23), (N/A), AUTO-BW
(5250 - 5350 @ 80), (N/A, 24), (0 ms), DFS, AUTO-BW
(5470 - 5730 @ 160), (N/A, 24), (0 ms), DFS
(5730 - 5850 @ 80), (N/A, 30), (N/A), AUTO-BW
(5850 - 5895 @ 40), (N/A, 27), (N/A), NO-OUTDOOR, AUTO-BW, PASSIVE-SCAN
(5925 - 7125 @ 320), (N/A, 12), (N/A), NO-OUTDOOR, PASSIVE-SCAN
(57240 - 71000 @ 2160), (N/A, 40), (N/A)
phy#0 (self-managed)
country US: DFS-UNSET
(2402 - 2437 @ 40), (6, 22), (N/A), AUTO-BW, NO-HT40MINUS, NO-80MHZ, NO-160MHZ
(2422 - 2462 @ 40), (6, 22), (N/A), AUTO-BW, NO-80MHZ, NO-160MHZ
(2447 - 2482 @ 40), (6, 22), (N/A), AUTO-BW, NO-HT40PLUS, NO-80MHZ, NO-160MHZ
(5170 - 5190 @ 160), (6, 22), (N/A), AUTO-BW, NO-HT40MINUS
(5190 - 5210 @ 160), (6, 22), (N/A), AUTO-BW, NO-HT40PLUS
(5210 - 5230 @ 160), (6, 22), (N/A), AUTO-BW, NO-HT40MINUS
(5230 - 5250 @ 160), (6, 22), (N/A), AUTO-BW, NO-HT40PLUS
(5250 - 5270 @ 160), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40MINUS, PASSIVE-SCAN
(5270 - 5290 @ 160), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40PLUS, PASSIVE-SCAN
(5290 - 5310 @ 160), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40MINUS, PASSIVE-SCAN
(5310 - 5330 @ 160), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40PLUS, PASSIVE-SCAN
(5490 - 5510 @ 240), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40MINUS, PASSIVE-SCAN
(5510 - 5530 @ 240), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40PLUS, PASSIVE-SCAN
(5530 - 5550 @ 240), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40MINUS, PASSIVE-SCAN
(5550 - 5570 @ 240), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40PLUS, PASSIVE-SCAN
(5570 - 5590 @ 240), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40MINUS, PASSIVE-SCAN
(5590 - 5610 @ 240), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40PLUS, PASSIVE-SCAN
(5610 - 5630 @ 240), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40MINUS, PASSIVE-SCAN
(5630 - 5650 @ 240), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40PLUS, PASSIVE-SCAN
(5650 - 5670 @ 80), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40MINUS,
NO-160MHZ, PASSIVE-SCAN
(5670 - 5690 @ 80), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40PLUS,
NO-160MHZ, PASSIVE-SCAN
(5690 - 5710 @ 80), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40MINUS,
NO-160MHZ, PASSIVE-SCAN
(5710 - 5730 @ 80), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40PLUS,
NO-160MHZ, PASSIVE-SCAN
(5735 - 5755 @ 80), (6, 22), (N/A), AUTO-BW, NO-HT40MINUS, NO-160MHZ
(5755 - 5775 @ 80), (6, 22), (N/A), AUTO-BW, NO-HT40PLUS, NO-160MHZ
(5775 - 5795 @ 80), (6, 22), (N/A), AUTO-BW, NO-HT40MINUS, NO-160MHZ
(5795 - 5815 @ 80), (6, 22), (N/A), AUTO-BW, NO-HT40PLUS, NO-160MHZ
(5815 - 5835 @ 40), (6, 22), (N/A), AUTO-BW, NO-HT40MINUS, NO-80MHZ, NO-160MHZ
_________________snip_________________
I wanted to call out the DFS-UNSET setting on phy#0
Dave.
On Sunday 04 Dec 2022 ? 10:37:42 (+0100), Thorsten Leemhuis wrote:
> That makes me (as a outsider that has no real knowledge about the inner
> workings of the Linux Wifi subsystem) wonder: Does it work in Windows?
No it does not.
More precisely, it used to work with older Intel drivers that (I
suppose) ignored this.
But starting from I don't remember which version it stopped working,
same behaviour as Linux.
--
Maxime
On Thu, Dec 1, 2022 at 5:33 AM Coelho, Luciano <[email protected]> wrote:
>
> On Thu, 2022-12-01 at 11:14 +0100, Thorsten Leemhuis wrote:
> > Hi, this is your Linux kernel regression tracker.
> >
> > Luca, I noticed a regression report in bugzilla where I'd like your
> > advice on. To quote https://bugzilla.kernel.org/show_bug.cgi?id=216753
>
> Hi Thorsten wearing-the-regression-hat, ????
>
> I'm not the maintainer of iwlwifi anymore, so I'm adding the new
> maintainer here, Gregory Greenman.
>
> Gregory, can you take a look?
>
@Gregory Greenman as I'm sure this got buried over the holidays, can
you take a look at this and advise? This is definitely a regression,
but I don't think a lot of people are noticing it or don't yet have
6ghz access points. I can write up a patch removing the offending
commit (698b166ed), or I can add an iwlwifi option to ignore the 6e
ACPI bit. Which would you prefer?
Dell has been of little help which I pretty much expected.
@Luciano, as you were the author of the original change, and I'm not
familiar enough with ACPI, is the below code reading the enable bits
from the BIOS ACPI table or is this somehow coming out of the network
card through some UEFI extensions? I'm trying to figure out which of
Dell or Intel need to update their firmware? I think some Lenovo's
have similar problems, so I suspect it's a BIOS ACPI table problem.
ret = iwl_acpi_get_dsm_u32(mvm->fwrt.dev, 0,
DSM_FUNC_ENABLE_6E,
&iwl_guid, &value);
Thanks,
Dave.
On Sun, Dec 4, 2022 at 3:37 AM Thorsten Leemhuis
<[email protected]> wrote:
>
> Does it work in Windows?
That's an interesting question. I did some searching and apparently a
number of other OEMs are all having issues with this even under
windows.
https://www.dell.com/community/XPS/Does-the-XPS-9520-support-Wi-Fi6E-6GHz/td-p/8229808
https://www.reddit.com/r/framework/comments/t0ghsc/fix_for_6_ghz_wifi_on_the_intel_ax210/
If I had to guess, I'd suspect that Intel has pushed similar checking
of ACPI into the windows driver.
Can we just get this terrible code ripped out until the OEMs get their
act together? This is really bad user experience.
On Tue, 2023-01-03 at 11:37 -0600, Dave Chiluk wrote:
> On Thu, Dec 1, 2022 at 5:33 AM Coelho, Luciano <[email protected]> wrote:
> >
> > On Thu, 2022-12-01 at 11:14 +0100, Thorsten Leemhuis wrote:
> > > Hi, this is your Linux kernel regression tracker.
> > >
> > > Luca, I noticed a regression report in bugzilla where I'd like your
> > > advice on. To quote https://bugzilla.kernel.org/show_bug.cgi?id=216753
> >
> > Hi Thorsten wearing-the-regression-hat, ????
> >
> > I'm not the maintainer of iwlwifi anymore, so I'm adding the new
> > maintainer here, Gregory Greenman.
> >
> > Gregory, can you take a look?
> >
>
> @Gregory Greenman as I'm sure this got buried over the holidays, can
> you take a look at this and advise? This is definitely a regression,
> but I don't think a lot of people are noticing it or don't yet have
> 6ghz access points. I can write up a patch removing the offending
> commit (698b166ed), or I can add an iwlwifi option to ignore the 6e
> ACPI bit. Which would you prefer?
>
> Dell has been of little help which I pretty much expected.
>
> @Luciano, as you were the author of the original change, and I'm not
> familiar enough with ACPI, is the below code reading the enable bits
> from the BIOS ACPI table or is this somehow coming out of the network
> card through some UEFI extensions? I'm trying to figure out which of
> Dell or Intel need to update their firmware? I think some Lenovo's
> have similar problems, so I suspect it's a BIOS ACPI table problem.
>
> ret = iwl_acpi_get_dsm_u32(mvm->fwrt.dev, 0,
> DSM_FUNC_ENABLE_6E,
> &iwl_guid, &value);
Dave, this code was added there for a reason. But as I said, I'm not
working with WiFi anymore, so I raised the question internally and
Gregory or someone else will respond to you with the details soon.
--
Cheers,
Luca.
Hi Dave,
On Tue, 2023-01-03 at 11:37 -0600, Dave Chiluk wrote:
> On Thu, Dec 1, 2022 at 5:33 AM Coelho, Luciano <[email protected]> wrote:
> >
> > On Thu, 2022-12-01 at 11:14 +0100, Thorsten Leemhuis wrote:
> > > Hi, this is your Linux kernel regression tracker.
> > >
> > > Luca, I noticed a regression report in bugzilla where I'd like your
> > > advice on. To quote https://bugzilla.kernel.org/show_bug.cgi?id=216753
> >
> > Hi Thorsten wearing-the-regression-hat, ????
> >
> > I'm not the maintainer of iwlwifi anymore, so I'm adding the new
> > maintainer here, Gregory Greenman.
> >
> > Gregory, can you take a look?
> >
>
> @Gregory Greenman as I'm sure this got buried over the holidays, can
> you take a look at this and advise? This is definitely a regression,
> but I don't think a lot of people are noticing it or don't yet have
> 6ghz access points. I can write up a patch removing the offending
> commit (698b166ed), or I can add an iwlwifi option to ignore the 6e
> ACPI bit. Which would you prefer?
>
> Dell has been of little help which I pretty much expected.
>
I'll try to explain, the problem here is not technical. After some
internal checks, it appears that we (wifi driver) aren't allowed to
decide if 6E should be enabled or not. Because of the legal restrictions,
OEM should make this decision and enable/disable 6E in the BIOS. This
commit only gets the value from the BIOS and configures the firmware
accordingly. So, unfortunately, legal restriction is the reason we cannot
revert/overwrite 6E enablement...
> @Luciano, as you were the author of the original change, and I'm not
> familiar enough with ACPI, is the below code reading the enable bits
> from the BIOS ACPI table or is this somehow coming out of the network
> card through some UEFI extensions? I'm trying to figure out which of
> Dell or Intel need to update their firmware? I think some Lenovo's
> have similar problems, so I suspect it's a BIOS ACPI table problem.
>
> ret = iwl_acpi_get_dsm_u32(mvm->fwrt.dev, 0,
> DSM_FUNC_ENABLE_6E,
> &iwl_guid, &value);
It comes from the BIOS ACPI table.
>
> Thanks,
> Dave.
On Thu, Jan 5, 2023 at 12:15 AM Greenman, Gregory
<[email protected]> wrote:
>
> I'll try to explain, the problem here is not technical. After some
> internal checks, it appears that we (wifi driver) aren't allowed to
> decide if 6E should be enabled or not. Because of the legal restrictions,
> OEM should make this decision and enable/disable 6E in the BIOS. This
> commit only gets the value from the BIOS and configures the firmware
> accordingly. So, unfortunately, legal restriction is the reason we cannot
> revert/overwrite 6E enablement...
>
Thank you Gregory, I've been reading between the lines, and this is
pretty much what I expected you to say. So in the past when
OEMs/systems manufacturers have been irresponsible/inept like this we
have implemented flags to force ignore the values coming out of the
bios. As it's now obvious that the problem here is a legal/regulatory
issue, I'd hope that having a force flag would be acceptable from a
that perspective. I'm no lawyer, but I expect once a user decides to
explicitly set a force flag to ignore the bios values I'd suspect the
responsibility would shift from the manufacturers and back onto the
user.
Would such a patch be theoretically acceptable? If so I'll write up a
patch to do this and submit it next week hopefully.
On Fri, 2023-01-06 at 09:37 -0600, Dave Chiluk wrote:
> On Thu, Jan 5, 2023 at 12:15 AM Greenman, Gregory
> <[email protected]> wrote:
> >
> > I'll try to explain, the problem here is not technical. After some
> > internal checks, it appears that we (wifi driver) aren't allowed to
> > decide if 6E should be enabled or not. Because of the legal restrictions,
> > OEM should make this decision and enable/disable 6E in the BIOS. This
> > commit only gets the value from the BIOS and configures the firmware
> > accordingly. So, unfortunately, legal restriction is the reason we cannot
> > revert/overwrite 6E enablement...
> >
> Thank you Gregory, I've been reading between the lines, and this is
> pretty much what I expected you to say. So in the past when
> OEMs/systems manufacturers have been irresponsible/inept like this we
> have implemented flags to force ignore the values coming out of the
> bios. As it's now obvious that the problem here is a legal/regulatory
> issue, I'd hope that having a force flag would be acceptable from a
> that perspective. I'm no lawyer, but I expect once a user decides to
> explicitly set a force flag to ignore the bios values I'd suspect the
> responsibility would shift from the manufacturers and back onto the
> user.
>
> Would such a patch be theoretically acceptable? If so I'll write up a
> patch to do this and submit it next week hopefully.
Sorry for the long delay...
We looked at it again and this particular scenario looks more like some
bug maybe in the firmware since in US it should be enabled by default.
Can I ask to collect a trace-cmd dump for the case when it doesn't
work with "-e iwlwifi -e mac80211 -e cfg80211 -e iwlwifi_msg"?