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)
Severity: normal CC: bugzilla.kernel.org, buo.ren.lin, dglt, dyegomb, fahad, holishing, intelfx, kamil.54002, linuxwifi, luca, nishant.119, 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]

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
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.
another user, same problem.
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`

`iwlist chan`

`iw reg get`

 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`

`iwlist chan`

`iw reg get`

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)