Created attachment 285259 [details] iwlwifi firmware version When I try to connect a 5Ghz wifi with a 80Mhz my Intel 9260 crash in loop.
Created attachment 285261 [details] dmesg
Created attachment 285263 [details] iw wlp58s0 info
Created attachment 285265 [details] iwconfig wlp58s0
Created attachment 285267 [details] dmesg without call trace
Created attachment 285269 [details] ping 8.8.8.8
Created attachment 285271 [details] lspci -vvv
This problem affects me too. 9260 in T460p (same in T480s) Thinkpads. Identical dmesg output. I have tried Ubuntu 19.10 and Fedora 31 beta. It seems to be linked to 5.3 Everything works fine on earlier kernels (tested on Ubuntu 19.04 and Fedora 30). Crashes occur as soon as traffic starts with 5GHz. 80 or 40Mhz, no difference.
We have a suspect of what this may be. We will look into. But to be sure, can you confirm whether that's the first SYSASSERT (or any iwlwifi error) that you see? The dmesg is truncated, so I can be sure there was nothing before that could be relevant.
This is dmesg | grep iwlw (Ubuntu 19.10 kernel 5.3.0-18-generic) [ 3.233876] iwlwifi 0000:03:00.0: enabling device (0000 -> 0002) [ 3.279689] iwlwifi 0000:03:00.0: Found debug destination: EXTERNAL_DRAM [ 3.279692] iwlwifi 0000:03:00.0: Found debug configuration: 0 [ 3.279973] iwlwifi 0000:03:00.0: loaded firmware version 46.6bf1df06.0 op_mode iwlmvm [ 3.307919] iwlwifi 0000:03:00.0: Detected Intel(R) Wireless-AC 9260 160MHz, REV=0x324 [ 3.315655] iwlwifi 0000:03:00.0: Applying debug destination EXTERNAL_DRAM [ 3.316007] iwlwifi 0000:03:00.0: Allocated 0x00400000 bytes for firmware monitor. [ 3.357200] iwlwifi 0000:03:00.0: base HW address: 64:5d:86:92:e2:d5 [ 3.428766] iwlwifi 0000:03:00.0 wlp3s0: renamed from wlan0 [ 4.718761] iwlwifi 0000:03:00.0: Applying debug destination EXTERNAL_DRAM [ 4.833787] iwlwifi 0000:03:00.0: Applying debug destination EXTERNAL_DRAM [ 4.900970] iwlwifi 0000:03:00.0: FW already configured (0) - re-configuring
Created attachment 285587 [details] journalctl -f output during crash This is the complete journalctl -f output when the problem manifests. This is the worst version of it that leads to complete system freeze with very little control as the touchpad is also lost (see end of file for psmouse.1) The message starts with the mention of "HW error, resetting before reading" but the wifi works fine in older kernels (5.0.32, Ubuntu 19.04) and Windows 10. There is a different version of the crash with different output and not as severe lock up (I can barely type sudo reboot compared to ending up hard-resetting when the above lock up takes place. I will follow it.
Created attachment 285589 [details] journalctl -f output during crash (other version) This crash is "softer" than the other, I still have control of the touchpad/trackpoint, choppy, but enough to get to a terminal and type sudo reboot. There is no mention of HW error, but rather a SW Error at the beginning. Needless to say bluetooth connectivity is gone in both cases. These logs are from Ubuntu 19.10, but the EXACT logs were produced with Fedora 31 beta (also kernel 5.3). I was not able to reproduce this with older kernels (Fedora 30 kernel 5.1 and Ubuntu 19.04 kernel 5.0.32). I hope this helps.
Created attachment 285591 [details] journalctl -f output during crash (2.4GHz with different output) This is fresh. Not as catastrophic. After it completed the system works fine. It even re-established wifi connection and bluetooth works. Softer version of crash but with some different output. (Ubuntu 19.10, kernel 5.3.0-18)
I can confirm that using this dkms backport here: https://gitlab.com/vicamo/backport-iwlwifi-dkms/tree/ubuntu/eoan for Ubuntu 18.10 has worked. Wifi works flawlessly with this. Obviously not a general solution (and I have no idea what this does), but a way out for Ubuntu 18.10. May this info helps. Thanks.
(In reply to Alex Kampas from comment #13) > I can confirm that using this dkms backport here: > https://gitlab.com/vicamo/backport-iwlwifi-dkms/tree/ubuntu/eoan > > for Ubuntu 18.10 has worked. Wifi works flawlessly with this. > > Obviously not a general solution (and I have no idea what this does), but a > way out for Ubuntu 18.10. > > May this info helps. > > Thanks. Sadly this did not work. Some bootups will be fine for as long as I work (few hours). Then I reboot and the problem manifests again. As such this backport is not a solution. Any updates on this issue? Thanks
I have also been suffering from this bug (although I'm not exactly sure it's just this bug). Past month the wifi driver has been acting enough, both crashing and dropping connection on high trafic 5GHz (downloading a torrent for example), and with reaaaaally low speeds (<1mbps) on 2.4GHz.
Created attachment 286041 [details] journal with segfault I am also experiencing this same bug. I attach two different iwlwifi segfaults, they both happened after ~30m of intense wifi usage (Using steam remote play on via wifi). If you want me to test anything it's quite easy for me to reproduce the bug.
Created attachment 286043 [details] Journal, different error
I am also experiencing this bug on kernel 5.4, with an AC 9260 con a Dell XPS 15 9570. This doesn't happen at all on kernel 5.2 or lower. But happens on kernels 5.3 or higher.
It seems to have been fixed on the kernel 5.4.6. Yesterday I was testing it for a long time and it didn't segfault even once where usually it would have at least 5-7 times. Lenovo T490 with AC 9260. Using iwd and systemd-network.
Great, thanks for reporting! I hope the other users who had this issue can also confirm so we can close this bug.
I will try it and report back. If you dual boot Windows 10, can you please test booting to Windows, then back to Linux and see if it still works. My experience was that I had much more trouble after I had rebooted from Windows compared to long stints of using linux. Thanks.
(In reply to Alex Kampas from comment #21) > I will try it and report back. > > If you dual boot Windows 10, can you please test booting to Windows, then > back to Linux and see if it still works. > > My experience was that I had much more trouble after I had rebooted from > Windows compared to long stints of using linux. > > Thanks. I am not dual-booting windows, can't test it sorry :/ I usually saw the error after 20-30min of streaming a game from my PC to my laptop via Parsec/Steam remote play on the 5Ghz wifi. Yesterday I played for a few hours and didn't see the error even once, so it seems fixed on my setup.
I can confirm this issue has been fixed in 5.4.8. Today I switched to this kernel and after using 5ghz network for more than 8 hours, not a single panic or slowing down occurred and wifi work like a charm now.
Great, thanks for reporting! We have two users confirming this is fixed now. Closing the bug.
(In reply to Luca Coelho from comment #24) > Great, thanks for reporting! > > We have two users confirming this is fixed now. Closing the bug. Problem still here in kernel 5.4.7 (openSUSE Tumbleweed) see attachment bellow. PS: Something strange I tried to make an hotspot with my Xiaomi phone (5Ghz band) and in this case no dmesg output et WiFi work great if I connect to it, but with all other hotspot I tried I had no luck.
Created attachment 286913 [details] dmesg and other logs with a 5.4.7 kernel
Onur said in comment #23 that it doesn't happen for him anymore on kernel 5.4.8. Can you try that?
I'm also affected (same firmware version, same traceback) with kernel Ubuntu 5.4.0-52.57~18.04.1-generic 5.4.65 Has anyone at Intel really worked on this more-than-one-year-old bug?
Same error on my AC 9560 but I face the error only when the channel 36 is used with 80MHz bandwidth. Ciao luigi Some info: Linux abc 5.13.0-21-generic #21-Ubuntu SMP Tue Oct 19 08:59:28 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux Firmware version: 46.6b541b68.0 9000-pu-b0-jf-b0-46.ucode op_mode iwlmvm 00:14.3 Network controller: Intel Corporation Cannon Lake PCH CNVi WiFi (rev 10) DeviceName: Onboard - Ethernet Subsystem: Intel Corporation Wireless-AC 9560 [Jefferson Peak] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 16 IOMMU group: 8 Region 0: Memory at ed31c000 (64-bit, non-prefetchable) [size=16K] Capabilities: [c8] Power Management version 3 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME- Capabilities: [d0] MSI: Enable- Count=1/1 Maskable- 64bit+ Address: 0000000000000000 Data: 0000 Capabilities: [40] Express (v2) Root Complex Integrated Endpoint, MSI 00 DevCap: MaxPayload 128 bytes, PhantFunc 0 ExtTag- RBE- FLReset+ DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq- RlxdOrd+ ExtTag- PhantFunc- AuxPwr+ NoSnoop+ FLReset- MaxPayload 128 bytes, MaxReadReq 128 bytes DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr+ TransPend- DevCap2: Completion Timeout: Range B, TimeoutDis+ NROPrPrP- LTR+ 10BitTagComp- 10BitTagReq- OBFF Via WAKE#, ExtFmt- EETLPPrefix- EmergencyPowerReduction Not Supported, EmergencyPowerReductionInit- FRS- AtomicOpsCap: 32bit- 64bit- 128bitCAS- DevCtl2: Completion Timeout: 16ms to 55ms, TimeoutDis- LTR+ OBFF Disabled, AtomicOpsCtl: ReqEn- Capabilities: [80] MSI-X: Enable+ Count=16 Masked- Vector table: BAR=0 offset=00002000 PBA: BAR=0 offset=00003000 Capabilities: [100 v0] Null Capabilities: [14c v1] Latency Tolerance Reporting Max snoop latency: 0ns Max no snoop latency: 0ns Capabilities: [164 v1] Vendor Specific Information: ID=0010 Rev=0 Len=014 <?> Kernel driver in use: iwlwifi