Bug 205695

Summary: [iwlwifi] 9260AC crashes with lar_disable=1
Product: Drivers Reporter: hexchain (i)
Component: network-wirelessAssignee: DO NOT USE - assign "network-wireless-intel" component instead (linuxwifi)
Status: CLOSED CODE_FIX    
Severity: normal CC: aiyengar, andrej.gelenberg, bugzilla.kernel.org, buo.ren.lin, dglt, dyegomb, fahad, gruzija, intelfx, irherder, kamil.54002, linuxwifi, luca, nishant.119, philipp+Kernel, quent.haas, schmidicom
Priority: P1    
Hardware: Intel   
OS: Linux   
Kernel Version: 5.4.0 Tree: Mainline
Regression: Yes
Attachments: dmesg
dmesg with iwlwifi debug=0x00014004 (IWL_DL_FW | IWL_DL_LAR | IWL_DL_HCMD)

Description hexchain 2019-11-28 19:57:21 UTC
Created attachment 286105 [details]
dmesg

Distro: Arch Linux

Since 5.4, if lar_disable=1 is set, iwlwifi reports a crash when trying to bring the interface up.

# ip l s wlp58s0 up
RTNETLINK answers: Input/output error

Dmesg is attached. Unfortunately, I failed to collect a firmware dump, even with the debug firmware.

% ethtool -i wlp58s0
driver: iwlwifi
version: 5.4.0-arch1-1
firmware-version: 46.6bf1df06.0
expansion-rom-version: 
bus-info: 0000:3a:00.0
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: no
Comment 1 hexchain 2019-11-28 20:10:19 UTC
Created attachment 286107 [details]
dmesg with iwlwifi debug=0x00014004 (IWL_DL_FW | IWL_DL_LAR | IWL_DL_HCMD)
Comment 2 Fahad 2019-12-05 23:45:01 UTC
Same on Slackware and Arch.


Kernels: 5.4.1 & 5.4.2 are both broken.

Kernel: 5.3.8 works just fine.

WiFi card is: Intel 9560
Comment 3 Kamil Iskra 2019-12-13 23:32:47 UTC
I'm seeing the same symptoms with Intel 8265. Works with 5.3, fails with 5.4.

Removing lar_disable=Y works it around.

There's a bug entry on Arch, https://bugs.archlinux.org/task/64703, where somebody bisected it and came up with the following patch: https://bugs.archlinux.org/task/64703?getfile=18121. It worked for me as well...
Comment 4 Luca Coelho 2019-12-16 19:38:52 UTC
Why are you normally disabling LAR? This is an old parameter that was used only when LAR was still under development.  I'll actually remove it from the driver now, since the end-users are not supposed to disable it.

This bug may not be directly related to LAR, though, but related to something in the number of channels or something like, so I won't close this bug yet.
Comment 5 Kamil Iskra 2019-12-16 20:06:03 UTC
I believe I originally disabled it because when it was enabled, I could not use "iw reg set".  So LAR seemed like an anti-feature.  See, e.g., https://unix.stackexchange.com/questions/286258/intel-wireless-7265d-iw-shows-wrong-regulatory-information

I don't know if that was fixed in the meantime or if I fundamentally misunderstood the purpose of LAR for the beginning.  I would welcome any insight you may have.
Comment 6 Luca Coelho 2019-12-16 20:15:28 UTC
This is a feature where the FW listens to the environment (mainly beacons and probe_responses from surrounding APs) and detects the location accordingly.  The FW has an algorithm to make this decision without relying on the userspace to provide the location information.

That's why you can't change the regulatory settings from the userspace anymore.  Disabling LAR doesn't help you and can potentially cause problems as the one you experienced.

I'll proceed in removing this option and then mark this bug as closed.

Thanks for reporting! :)
Comment 7 Luca Coelho 2019-12-16 20:28:32 UTC
I have created the patch internally and will close this bug once I send it upstream.
Comment 8 Ivan Shapovalov 2019-12-18 18:49:00 UTC
Unconditionally relying on information from adjacent APs sounds like an anti-feature indeed. Will there be no other way to disable this behavior?
Comment 9 Luca Coelho 2019-12-18 19:28:40 UTC
It's not unconditionally, there is some logic that makes the decision trustworthy.
Comment 10 Nishant Kumar 2019-12-29 03:07:00 UTC
I am having the same problem

Kernel: 5.3.x (x : 8,13) works perfectly fine

Kernel: 5.4.x (x : 2,3,4,6) is broken

WiFi card is: Intel 9560
Comment 11 dglt 2020-01-06 14:46:33 UTC
(In reply to Luca Coelho from comment #4)
> Why are you normally disabling LAR? This is an old parameter that was used
> only when LAR was still under development.  I'll actually remove it from the
> driver now, since the end-users are not supposed to disable it.
> 
> This bug may not be directly related to LAR, though, but related to
> something in the number of channels or something like, so I won't close this
> bug yet.

please dont remove `lar_disable` functionality, LAR is a great feature in theory but when it fails to work properly if fails spectacularly. without disabling LAR, 5ghz ac channels get disabled except for 149@20mhz and only if i lock it to 20mhz on the router. even when im able to get the card to detect "country US: DFS-FCC" it will also show "country ID: DFS-UNSET" just below it on `iw reg get` output and it disables all the channels i should available to me here in the US. i do not live near any radar stations and every non-intel device i own does not have this problem. this same issue happens on the oem 3165ngw, 8265ngw, and 9260. 

on linux im able to remedy this with lar_disable=Y and get the full 1733mbit/s up/down 160mhz link speed but only with that module option. on windows there is no lar_disable and im left with using a second router as a network bridge running a lan cable from it. 

related links, steps i've taken over the last few months since the issue began.
https://forums.intel.com/s/question/0D50P00004VggYA/wireless-ac-9260-regulatory-lardrs-breaks-5ghz-functionality?language=en_US
another user, same problem.
https://forums.intel.com/s/question/0D70P000006drPk/wireless-ac-8265-ax-200-sets-the-incorrect-regulatory-domain
Comment 12 dglt 2020-01-06 17:40:51 UTC
additional supporting logs.

##
with no option other than enabling debug (lar_disable=0)
`dmesg|grep -i iwl`
https://pastebin.com/uZdptEHb

`iwlist chan`
https://pastebin.com/8wQZZp1L

`iw reg get`
 https://pastebin.com/FuziP013

 lar detects US like it should and then goes on to detect "ID" indonesia which
 disables all 5ghz channels except 149-161 and only at 20mhz width.


##
with debug and lar_disable=1 

`dmesg|grep -i iwl`
https://pastebin.com/PMcHrxMP

`iwlist chan`
https://pastebin.com/W4HKKwYE

`iw reg get`
https://pastebin.com/8wQZZp1L

with lar_disable, everything works as it should. only US is detected and my channels 
dont get crippled.
Comment 13 ๆž—ๅšไป 2020-05-24 11:27:46 UTC
Luca, I would like to ask whether the default behavior would be if the surrounding radio signal is not available (like, in a room where all Wi-Fi signals are isolated or a (very) secluded area where no AP signals are even available)?

Also IMO the driver/firmware should at least allow the user to override the regulatory settings when LAR doesn't detect proper regulatory regions.
Comment 14 N.Q. Haas 2020-10-26 12:00:03 UTC
As noted above, `lar_disable` is useful when LAR isn't working correctly and there are plenty of examples of LAR not working correctly out on Intel's community web forums.  Often the 'answer' on said forums is to submit a troubleticket to one's OEM, but often (at least historically), many OEMs don't even support Linux on their notebook computers.  IMO, keeping the `lar_disable` debugging / troubleshooting / override available is useful, and given how it is buried, doubt 'regular' users are going to stumble upon it and flip it on unintentionally.

Is the logic that implements how LAR works and makes the region determination on the adapter well documented and open-source?  If not, then it is concerning we are losing the ability to disable a blackbox.

To further expand on Comment 13, what happens if there are (intentionally or unintentionally) misconfigured APs beyond the control of the user that causes LAR to make an incorrect region determination?
Comment 15 Stefan Schmid 2021-01-14 10:45:57 UTC
Automatically detecting the Wi-Fi region is a nice idea but in far too many cases it simply doesn't work. And in precisely such cases, the user must be allowed to set this himself.

My case:
I live in Switzerland and my "Intel Corporation Dual Band Wireless-AC 8265" sets itself to "DE", which is strictly speaking illegal. And I no longer have the possibility to change this.

Please reverse this change!

Translated with www.DeepL.com/Translator (free version)
Comment 16 James M 2021-03-13 04:30:31 UTC
Same issue here, with an Intel 8260, my region is getting set to CN "self-managed" while I'm actually in the US. Whatever algorithm is being used by the firmware - it's making an incorrect decision and I can't override it.
Comment 17 Andriy Perevortkin 2021-05-12 22:33:25 UTC
The decision to take away disable_lar option was very wrong.
Please reinstate it or provide another mechanism to allow users to override dumb decisions made by dumb firmware.

This is another reason to stay away from intel hardware.
Comment 18 Andrej Gelenberg 2021-09-27 03:12:04 UTC
+1 From my side. Looks like without it it's impossible to start hostapd on 5Ghz, because all channels are either NO-IR or straight disables. iw reg set is showing fine until hostap try to start, then it shows up like following:
$ iw list
...
               Frequencies:
                        * 5180 MHz [36] (22.0 dBm) (no IR)
                        * 5200 MHz [40] (22.0 dBm) (no IR)
                        * 5220 MHz [44] (22.0 dBm) (no IR)
                        * 5240 MHz [48] (22.0 dBm) (no IR)
                        * 5260 MHz [52] (22.0 dBm) (no IR, radar detection)
                        * 5280 MHz [56] (22.0 dBm) (no IR, radar detection)
                        * 5300 MHz [60] (22.0 dBm) (no IR, radar detection)
                        * 5320 MHz [64] (22.0 dBm) (no IR, radar detection)
                        * 5340 MHz [68] (disabled)
                        * 5360 MHz [72] (disabled)
                        * 5380 MHz [76] (disabled)
                        * 5400 MHz [80] (disabled)
                        * 5420 MHz [84] (disabled)
                        * 5440 MHz [88] (disabled)
                        * 5460 MHz [92] (disabled)
                        * 5480 MHz [96] (disabled)
                        * 5500 MHz [100] (22.0 dBm) (no IR, radar detection)
                        * 5520 MHz [104] (22.0 dBm) (no IR, radar detection)
                        * 5540 MHz [108] (22.0 dBm) (no IR, radar detection)
                        * 5560 MHz [112] (22.0 dBm) (no IR, radar detection)
                        * 5580 MHz [116] (22.0 dBm) (no IR, radar detection)
                        * 5600 MHz [120] (22.0 dBm) (no IR, radar detection)
                        * 5620 MHz [124] (22.0 dBm) (no IR, radar detection)
                        * 5640 MHz [128] (22.0 dBm) (no IR, radar detection)
                        * 5660 MHz [132] (22.0 dBm) (no IR, radar detection)
                        * 5680 MHz [136] (22.0 dBm) (no IR, radar detection)
                        * 5700 MHz [140] (22.0 dBm) (no IR, radar detection)
                        * 5720 MHz [144] (22.0 dBm) (no IR, radar detection)
                        * 5745 MHz [149] (22.0 dBm) (no IR)
                        * 5765 MHz [153] (22.0 dBm) (no IR)
                        * 5785 MHz [157] (22.0 dBm) (no IR)
                        * 5805 MHz [161] (22.0 dBm) (no IR)
                        * 5825 MHz [165] (22.0 dBm) (no IR)
                        * 5845 MHz [169] (disabled)
                        * 5865 MHz [173] (disabled)
                        * 5885 MHz [177] (disabled)
                        * 5905 MHz [181] (disabled)

$ 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, AUTO-BW
        (57000 - 66000 @ 2160), (N/A, 40), (N/A)

phy#0 (self-managed)
country 00: 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 @ 80), (6, 22), (N/A), NO-OUTDOOR, AUTO-BW, IR-CONCURRENT, NO-HT40MINUS, NO-160MHZ, PASSIVE-SCAN
        (5190 - 5210 @ 80), (6, 22), (N/A), NO-OUTDOOR, AUTO-BW, IR-CONCURRENT, NO-HT40PLUS, NO-160MHZ, PASSIVE-SCAN
        (5210 - 5230 @ 80), (6, 22), (N/A), NO-OUTDOOR, AUTO-BW, IR-CONCURRENT, NO-HT40MINUS, NO-160MHZ, PASSIVE-SCAN
        (5230 - 5250 @ 80), (6, 22), (N/A), NO-OUTDOOR, AUTO-BW, IR-CONCURRENT, NO-HT40PLUS, NO-160MHZ, PASSIVE-SCAN
        (5250 - 5270 @ 80), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40MINUS, NO-160MHZ, PASSIVE-SCAN
        (5270 - 5290 @ 80), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40PLUS, NO-160MHZ, PASSIVE-SCAN
        (5290 - 5310 @ 80), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40MINUS, NO-160MHZ, PASSIVE-SCAN
        (5310 - 5330 @ 80), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40PLUS, NO-160MHZ, PASSIVE-SCAN
        (5490 - 5510 @ 80), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40MINUS, NO-160MHZ, PASSIVE-SCAN
        (5510 - 5530 @ 80), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40PLUS, NO-160MHZ, PASSIVE-SCAN
        (5530 - 5550 @ 80), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40MINUS, NO-160MHZ, PASSIVE-SCAN
        (5550 - 5570 @ 80), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40PLUS, NO-160MHZ, PASSIVE-SCAN
        (5570 - 5590 @ 80), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40MINUS, NO-160MHZ, PASSIVE-SCAN
        (5590 - 5610 @ 80), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40PLUS, NO-160MHZ, PASSIVE-SCAN
        (5610 - 5630 @ 80), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40MINUS, NO-160MHZ, PASSIVE-SCAN
        (5630 - 5650 @ 80), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40PLUS, NO-160MHZ, 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, IR-CONCURRENT, NO-HT40MINUS, NO-160MHZ, PASSIVE-SCAN
        (5755 - 5775 @ 80), (6, 22), (N/A), AUTO-BW, IR-CONCURRENT, NO-HT40PLUS, NO-160MHZ, PASSIVE-SCAN
        (5775 - 5795 @ 80), (6, 22), (N/A), AUTO-BW, IR-CONCURRENT, NO-HT40MINUS, NO-160MHZ, PASSIVE-SCAN
        (5795 - 5815 @ 80), (6, 22), (N/A), AUTO-BW, IR-CONCURRENT, NO-HT40PLUS, NO-160MHZ, PASSIVE-SCAN
        (5815 - 5835 @ 20), (6, 22), (N/A), AUTO-BW, IR-CONCURRENT, NO-HT40MINUS, NO-HT40PLUS, NO-80MHZ, NO-160MHZ, PASSIVE-SCAN