Bug 203891
|
Description
Tormen
2019-06-13 22:25:18 UTC
Created attachment 283263 [details]
2019-06-13 test-it.output.txt
Created attachment 283265 [details]
2019-06-13 test-it.journalctl.log
Created attachment 283267 [details]
2019-06-13 test-it.txt
From: "Grumbach, Emmanuel" <emmanuel.grumbach@intel.com> Subject: Re: [linuxwifi] regression with Wireless-AC 9560: Failed to load firmware chunk! -- Failed to run INIT ucode: -110 Date: Thu, 13 Jun 2019 20:30:58 +0000 Hey, 0000:00:14.3: CSR_MSIX_HW_INT_MASK_AD: 0X6e0001c7 0000:00:14.3: CSR_MSIX_HW_INT_CAUSES_AD: 0X00000080 What it means is that the only interrupt we have here is the RFKILL interrupt. It's not that the HW sent an interrupt and that it was masked or something... Very strange. Since it worked, we'll have to ask you bisect. Thanks. Created attachment 283285 [details]
2019-06-15_journalctl_-b.log working after reboot now (but not after rmmod / modprobe)
The laptop went low battery and shutdown overnight.
Directly after rebooting, now the failstate that I had seems gone and everything /seems/ to work again - see 2019-06-15_working-journalctl.log
I think, during the moment the problem occured and all my tests I might not have shutdown the machine, but actually just put it in stand-by or rebooted it!
Created attachment 283289 [details]
2019-06-15_test-it.output.txt
Now that it works after reboot (don't know why, because I did not change /anything/), rmmod and modprobe still don't work.
This is the output of test-it.sh
changes to test-it.sh:
* added 3 echo lines: START, NEXT, DONE
* added a sleep 3 after the `modprobe iwlwifi` allowing for things to settle first)
* added 3 `ip link` at the beginning, after rmmod and at the end because `iwctl device list` is empty , but there is a device wlo1 appearing !!
Created attachment 283291 [details]
2019-06-15_test-it.journalctl.log -- of new test-it run
Jun 15 18:50:42 huit kernel: iwlwifi 0000:00:14.3: loaded firmware version 46.3cfab8da.0 op_mode iwlmvm Jun 15 18:50:42 huit kernel: iwlwifi 0000:00:14.3: Detected Intel(R) Wireless-AC 9560 160MHz, REV=0x318 Jun 15 18:50:42 huit kernel: iwlwifi 0000:00:14.3: base HW address: 18:56:80:77:0d:58 Jun 15 18:50:42 huit kernel: iwlwifi 0000:00:14.3 wlo1: renamed from wlan0 Jun 15 18:50:42 huit kernel: iwlwifi 0000:00:14.3: RF_KILL bit toggled to disable radio. Jun 15 18:50:42 huit kernel: iwlwifi 0000:00:14.3: reporting RF_KILL (radio disabled) Jun 15 18:50:42 huit kernel: iwlwifi 0000:00:14.3: U iwl_run_init_mvm_ucode RFKILL while calibrating. Jun 15 18:50:42 huit kernel: iwlwifi 0000:00:14.3: Failed to start RT ucode: -132 So the modprobe after rmmod still results in a "Failed to start RT ucode" but this time with -132 ;) Created attachment 283293 [details]
fix candidate
Please try this patch.
ping? Pong. Really sorry. Was on a conference the last 2 days. Will try to test it today, latest tomorrow. Hi Emmanuel, I added your patch to 5.1.8 kernel (your debug patch is also still there :). Summary: Things changed, but I can't get it to work. In short: * Booting: All good. * RF-KILL keyboard-shortcut (on DELL laptop): turns off wifi (rfkill blocked) * RF-KILL keyboard-shortcut (on DELL laptop): pressing it again unblocks wlan0.... BUT I always have to manually bring the wireless interface up. Question: Who would be to blame for this?? once I manually `ip link set wlan0 up` things work again * BUT test-it.sh does not yet function. So rmmod .. modprobe won't get me a working wireless connection: wlan0 gets renamed to wlo1 by the kernel ... why?! / what does that mean?? * This was "DOWN" as well. When I tried to `ip link set wlo1 up` it, I saw: "iwlwifi 0000:00:14.3: BIOS contains WGDS but no WRDS" -- What does this mean ? / Do I need to worry about this? Tormen Created attachment 283355 [details]
2019-06-21 shell log (what I did inclusive output of test-it.sh and it's command)
Created attachment 283357 [details]
2019-06-21 test-it.journalctl.log -- of new test-it run
Created attachment 283359 [details]
2019-06-21 journalctl_between_rfkill-keyboard-shortcut_to-turn-OFF___until___to-turn-ON.log
Created attachment 283361 [details]
2019-06-21 journalctl_-b COMPLETE (boot until this moment)
The renaming is because systemd, not the kernel. The kernel won't UP the interface after rfkill, wpa_supplicant is in charge of this. Bottom line, the bug is fixed. Patches are queued for 5.2 Hi Emmanuel, many thanks for clarifying! I was using iwd which somehow did not want to work with the device `wlo1` and also trying to manually bringing it up resulted in it being set back to down again ... ... but with wpa_supplicant I can confirm it works. Only one strangeness: When I reran test-it.sh now the test did not finish as it got stuck during `iwctl device list` !? I ran an strace and will attach it. This is really strange, no? `ip link` works for instance. And this morning `iwctl device list` also worked. I'll also attach the journalctl but I did not see anything in there. Tormen. Created attachment 283375 [details]
2019-06-21 strace_iwctl_device_list.txt
Created attachment 283377 [details]
2019-06-21 journalctl from test-it.sh + subsequent strace iwctl device list
Hi Emmanuel, just noticed that also after a fresh reboot with your patch the `iwctl device list` command hangs forever every time :(( This new problem seems to coincide with me using your patch. Any idea? Tormen dmesg please... Boah, this is embarassing: I confused iwctl with iw :( iwctl is from iwd. I switched back to wpa_supplicant. Hence iwctl hangs ;) @Emmanuel: Thaaaaaaaaank you very much for the quick fix !!!! I ran into this problem on Dell Latitude 7400 2-in-1 and kernel 5.3.0-rc6 (last night's `master`). It seems I was running sys-kernel/linux-firmware-20190717. Upon investigation, I discovered sys-kernel/linux-firmware-20190815 contains iwlwifi-9000-pu-b0-jf-b0-46.ucode with a different filesize / checksum. After updating to 20190815, the system seems to behave more stable, at least the wifi adapter isn't crashing. Emmanuel, can you confirm that even though ucode filename may be exactly the same, it may have behavior impacting differences across linux-firmware releases? Hi Leho, Yes, we update the firmware and keep the same file name. The number in the filename is the FW API number and is matched against the kernel version (i.e. each kernel version supports a different range of FW API versions). We still make bugfixes to these firmwares and release them under the same FW API number. You can check the SHA1 of the firmware build in the WHENCE file and in the logs where you see something like this: iwlwifi 0000:00:14.3: loaded firmware version 46.3cfab8da.0 op_mode iwlmvm The first number in the firmware version is the API number, the second number is the SHA1 of the build (this changes when we release bugfixes) and the last number is for internal use and should always be 0 on public firmwares. I hope this clarifies. |