Bug 208599
| Summary: | iwlwifi: warning nl80211_get_reg_do | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | Serg Podtynnyi (serg) |
| Component: | network-wireless-intel | Assignee: | Default virtual assignee for network-wireless-intel (drivers_network-wireless-intel) |
| Status: | CLOSED CODE_FIX | ||
| Severity: | normal | CC: | amonakov, bkohler, chris2553, cruzki123, golan.ben.ami, linux, m1027, martin.stolpe, mike+lists, serg, t.clastres |
| Priority: | P1 | ||
| Hardware: | Intel | ||
| OS: | Linux | ||
| Kernel Version: | 5.7.9 | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
|
Description
Serg Podtynnyi
2020-07-17 11:48:56 UTC
Hope it's okay to add another warning here from dmesg. It appears to me to be either the same or very close. We've been discussing and bisecting it at Gentoo's here [1] as well as on iwd's mailing list [2]. [1] https://bugs.gentoo.org/746539 [2] https://lists.01.org/hyperkitty/list/iwd@lists.01.org/thread/PSQEBUVXJLMR7TB2DDVY2R6JNXYIQLSD/ The summary: iwd-1.7 was not hit, but 1.8 and 1.9 have been hit by the issue. The kernel has been bisected down to this commit: https://git.kernel.org/pub/scm/network/wireless/iwd.git/commit/?id=b43e915b989dcbb0fa763fb7f256e30fe7426f14 However, it may not be the real cause, maybe only revealing the issue. Still happening with linux 5.9.1. In the testbed iwd gets started via systemd (at least here). Note: Starting the service *after* the boot process manually does *not* crash. So, currently everything works, as the service gets restarted after the initial crash. Last but not least, the output of dmesg: [ 16.086329] ------------[ cut here ]------------ [ 16.086333] WARNING: CPU: 0 PID: 370 at net/wireless/nl80211.c:7284 nl80211_get_reg_do+0x1fc/0x230 [ 16.086334] CPU: 0 PID: 370 Comm: iwd Not tainted 5.8.13 #15 [ 16.086335] Hardware name: LENOVO 20KFCTO1WW/20KFCTO1WW, BIOS N20ET55W (1.40 ) 06/01/2020 [ 16.086336] RIP: 0010:nl80211_get_reg_do+0x1fc/0x230 [ 16.086338] Code: 00 00 00 48 89 ef e8 13 ff 85 ff 85 c0 0f 84 01 ff ff ff eb a6 48 89 ef 48 89 04 24 e8 4d ff e0 ff 48 8b 04 24 e9 43 ff ff ff <0f> 0b 48 89 ef e8 3a ff e0 ff b8 ea ff ff ff e9 2f ff ff ff e9 78 [ 16.086338] RSP: 0018:ffff9ab9c041bb98 EFLAGS: 00010202 [ 16.086339] RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000 [ 16.086340] RDX: ffff95472b7b0008 RSI: 0000000000000000 RDI: ffff95472b7b02e0 [ 16.086340] RBP: ffff9547264c1d00 R08: 0000000000000004 R09: ffff954728585014 [ 16.086340] R10: ffff954728581000 R11: 0000000000000001 R12: ffff9ab9c041bbf0 [ 16.086341] R13: 0000000000000000 R14: ffff954728585014 R15: ffff95472b7b02e0 [ 16.086341] FS: 00007f346c24e740(0000) GS:ffff95472e400000(0000) knlGS:0000000000000000 [ 16.086342] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 16.086342] CR2: 000055f2e8fc3010 CR3: 00000004222c2002 CR4: 00000000003606f0 [ 16.086343] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 16.086343] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 16.086344] Call Trace: [ 16.086346] genl_rcv_msg+0x1ae/0x2f0 [ 16.086348] ? genl_family_rcv_msg_attrs_parse.isra.0+0xd0/0xd0 [ 16.086349] netlink_rcv_skb+0x46/0x110 [ 16.086350] genl_rcv+0x1f/0x30 [ 16.086351] netlink_unicast+0x197/0x230 [ 16.086352] netlink_sendmsg+0x1ed/0x400 [ 16.086353] __sys_sendto+0x1d3/0x1f0 [ 16.086355] __x64_sys_sendto+0x21/0x30 [ 16.086356] do_syscall_64+0x4d/0x1d0 [ 16.086358] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 16.086360] RIP: 0033:0x7f346c3d862c [ 16.086361] Code: 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 41 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 21 45 31 c9 45 31 c0 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 6c e9 91 0c 04 00 0f 1f 80 00 00 00 00 55 48 [ 16.086361] RSP: 002b:00007fff38eb6978 EFLAGS: 00000246 ORIG_RAX: 000000000000002c [ 16.086362] RAX: ffffffffffffffda RBX: 000055f2e8faab00 RCX: 00007f346c3d862c [ 16.086362] RDX: 000000000000001c RSI: 000055f2e8fc2ac0 RDI: 0000000000000004 [ 16.086363] RBP: 000055f2e8fc1910 R08: 0000000000000000 R09: 0000000000000000 [ 16.086363] R10: 0000000000000000 R11: 0000000000000246 R12: 00007fff38eb6a08 [ 16.086364] R13: 000055f2e8fb4910 R14: 000055f2e8fb4790 R15: 0000000000000000 [ 16.086364] ---[ end trace a7bf7b4f3a41fe0a ]--- Thanks! I've been trying to track down the cause of this warning for a few days now. I think it's a combination of changes to both the kernel and iwd. The warning seems to arise because when iwd is launched, it tries to get regulatory domain information from the kernel. If the adapter (phy0) has not been set up at this point, the warning is produced. In my case, at this point in the boot wlan0 exists, but the associated phy0 does not. For now, i "fix" that situation by inserting "ip link set wlan0 up" into the init script at the point immediately before iwd is launched. Bringing up the WLAN appears to set up the the missing phy0 and the warning is no longer produced. This explains why the warning is seen during boot, but does not appear if the network is manually restarted after login. You may have guessed from my use of the term init script, that I don't use systemd on my system (which is based on Linux From Scratch). My init system is sysvinit-2.98. The following (currently unreviewed?) patch explains that warning is over-zealous and removes it: https://lore.kernel.org/linux-wireless/iwlwifi.20210409123755.ba2ea961f4ae.I8fde32d3196e860efa3b4ec464c42194195b42ec@changeid/ I've applied the patch at comment 3 to linux-5.12. Obviously, the warning splat has gone but more importantly, iwd still connects my laptop to mum wireless network and data transfer over the network works fine. Thanks, Alexander. I've applied the patch at comment 3 to linux-5.12. Obviously, the warning splat has gone but more importantly, iwd still connects my laptop to my wireless network and data transfer over the network works fine. Thanks, Alexander. Is there any progress on getting this fix upstream, please? I can't find the change in any tree on kernel.org. Ping. Any progress on moving this upstream, please? <frustrated_rant>Well, I give up! I provided an analysis of what I think the problem is 20 months ago and nothing has happened to materially change things! Nobody at Intel seems to care that a driver they maintain is out of step with a daemon which, it seems, they substantially maintain. Utter crap!!!!!</frustrated_rant> I have a better workaround than the one I described in comment 2 above. I have created the file /etc/modprobe.d/iwlwifi.conf with the following contents: softdep iwlwifi pre: cfg80211 options cfg80211 ieee80211_regdom=GB Obviously, you change iwlwifi on the first line to the name of the wireless driver on your system and change GB on the second line to the identifier for whatever country you live in. You can call the .conf file whatever you want except that it must have the .conf suffix. Sorry for not replying here, well, ever. Eventually, we have uploaded a different version of the fix for the issue, and reverted the patch mentioned above. This is the fix merged: eb09ae9 iwlwifi: mvm: load regdomain at INIT stage Thanks Golan. On 18/11/2021 10:16, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=208599 > > Golan Ben Ami (golan.ben.ami@intel.com) changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Status|NEW |RESOLVED > CC| |golan.ben.ami@intel.com > Resolution|--- |CODE_FIX > > --- Comment #10 from Golan Ben Ami (golan.ben.ami@intel.com) --- > Sorry for not replying here, well, ever. > Eventually, we have uploaded a different version of the fix for the issue, > and > reverted the patch mentioned above. > This is the fix merged: > eb09ae9 iwlwifi: mvm: load regdomain at INIT stage > Are there any plans to backport the patch to stable. It looks to me as if 5.4 and 5.10 both need the fix. Chris Sorry, my mistake - the fix has been backported to 5.10-stable. Please re-open if still relevant |