Instability in ALL stable and LTS distro kernels (IRQ #16 being disabled, PCIe bus errors, ath10k_pci) in Dell Inspiron 5567
Hello,
The following is the original thread, where a bug was reported to the linux-wireless and ath10k mailing lists. The specific bug has been detailed clearly here.
https://lore.kernel.org/linux-wireless/690B1DB2-C9DC-4FAD-8063-4CED659B1701@...
There is also a Bugzilla report by me, which was opened later: https://bugzilla.kernel.org/show_bug.cgi?id=220264
As stated, it is highly encouraged to check out all the logs, especially the line of IRQ #16 in /proc/interrupts.
Here is where all the logs are: https://gist.github.com/BandhanPramanik/ddb0cb23eca03ca2ea43a1d832a16180 (these logs are taken from an Arch liveboot)
On my daily driver, I found these on my IRQ #16:
16: 173210 0 0 0 IR-IO-APIC 16-fasteoi i2c_designware.0, idma64.0, i801_smbus
The fixes stated on the Reddit post for this Wi-Fi card didn't quite work. (But git-cloning the firmware files did give me some more time to have stable internet)
This time, I had to go for the GRUB kernel parameters.
Right now, I'm using "irqpoll" to curb the errors caused. "intel_iommu=off" did not work, and the Wi-Fi was constantly crashing even then. Did not try out "pci=noaer" this time.
If it's of any concern, there is a very weird error in Chromium-based browsers which has only happened after I started using irqpoll. When I Google something, the background of the individual result boxes shows as pure black, while the surrounding space is the usual greyish-blackish, like we see in Dark Mode. Here is a picture of the exact thing I'm experiencing: https://files.catbox.moe/mjew6g.png
If you notice anything in my logs/bug reports, please let me know. (Because it seems like Wi-Fi errors are just a red herring, there are some ACPI or PCIe-related errors in the computers of this model - just a naive speculation, though.)
Thanking you, Bandhan Pramanik
[+cc Jeff, ath10k maintainer]
On Thu, Jun 26, 2025 at 12:47:49AM +0530, Bandhan Pramanik wrote:
Hello,
The following is the original thread, where a bug was reported to the linux-wireless and ath10k mailing lists. The specific bug has been detailed clearly here.
https://lore.kernel.org/linux-wireless/690B1DB2-C9DC-4FAD-8063-4CED659B1701@...
There is also a Bugzilla report by me, which was opened later: https://bugzilla.kernel.org/show_bug.cgi?id=220264
As stated, it is highly encouraged to check out all the logs, especially the line of IRQ #16 in /proc/interrupts.
Here is where all the logs are: https://gist.github.com/BandhanPramanik/ddb0cb23eca03ca2ea43a1d832a16180 (these logs are taken from an Arch liveboot)
On my daily driver, I found these on my IRQ #16:
16: 173210 0 0 0 IR-IO-APIC 16-fasteoi i2c_designware.0, idma64.0, i801_smbus
The fixes stated on the Reddit post for this Wi-Fi card didn't quite work. (But git-cloning the firmware files did give me some more time to have stable internet)
This time, I had to go for the GRUB kernel parameters.
Right now, I'm using "irqpoll" to curb the errors caused. "intel_iommu=off" did not work, and the Wi-Fi was constantly crashing even then. Did not try out "pci=noaer" this time.
If it's of any concern, there is a very weird error in Chromium-based browsers which has only happened after I started using irqpoll. When I Google something, the background of the individual result boxes shows as pure black, while the surrounding space is the usual greyish-blackish, like we see in Dark Mode. Here is a picture of the exact thing I'm experiencing: https://files.catbox.moe/mjew6g.png
If you notice anything in my logs/bug reports, please let me know. (Because it seems like Wi-Fi errors are just a red herring, there are some ACPI or PCIe-related errors in the computers of this model - just a naive speculation, though.)
Your dmesg log is incomplete, and we would need to see the entire thing. It should start with something like this:
Linux version 6.8.0-60-generic (buildd@lcy02-amd64-054) (x86_64-linux-gnu-gcc-13 (Ubuntu 13.3.0-6ubuntu2~24.04) 13.3.0, GNU ld (GNU Binutils for Ubuntu) 2.42) #63-Ubuntu SMP PREEMPT_DYNAMIC Tue Apr 15 19:04:15 UTC 2025 (Ubuntu 6.8.0-60.63-generic 6.8.12)
Your lspci output doesn't include the necessary PCI details; collect it with "sudo lspci -vv".
We should pick the most serious problem and focus on that instead of trying to solve everything at once.
It sounds like the ath10k issue might be the biggest problem? If "options ath10k_core skip_otp=y" is a workaround for this problem, it looks like some ath10k firmware thing, probably unrelated to the PCI core.
Bjorn
Please ignore the last email (I haven't replied to everyone). Also, here's the actual updated dmesg (the previous one was the old one): https://gist.github.com/BandhanPramanik/ddb0cb23eca03ca2ea43a1d832a16180/raw...
On Thu, Jun 26, 2025 at 4:16 AM Bandhan Pramanik bandhanpramanik06.foss@gmail.com wrote:
Hello Bjorn,
First of all, thanks a LOT for replying.
I have included the files in my previous GitHub Gist. Sharing the raw files for easier analysis.
lspci -vv: https://gist.github.com/BandhanPramanik/ddb0cb23eca03ca2ea43a1d832a16180/raw... dmesg: https://gist.github.com/BandhanPramanik/ddb0cb23eca03ca2ea43a1d832a16180/raw...
On a different note, I had to use pci=noaer, so that the ring buffer wouldn't get cleared that fast.
Regarding the ath10k thing, none of the fixes worked this time. Only irqpoll worked. I don't know if it's because of a disparity b/w GNOME and KDE (because my daily driver is Fedora 42), but I'm 300% sure that it's not just the Wi-Fi that's the issue here. It's most probably a lot of issues here, and the harder issues to fix are usually the ones closer to the hardware.
Anyway, if you get something, please let me know.
Bandhan
Hello everyone,
I think I found it. I used irqpoll and I didn't experience any hiccups with my mouse performance. But the Wi-Fi was still malfunctioning.
To linux-pci and linux-acpi:
It's an ath10k problem, sure, but there's something definitely problematic happening if, in the normal state, these Wi-Fi bugs hamper the touchpad movement.
To ath10k and linux-wireless:
I tried out "options ath10k_core rawmode = 0" along with "skip_otp=y' and the Wi-Fi seems to work perfectly as of now. It might be the fix, it might not be either. But I think there's something more important to ask: Are there any good resources/documentation on referring to what the different key-value pairs mean? Like, what's the exact documentation through which people arrive at "rawmode=0" or "skip_otp=y"?
Bandhan
On 26 June 2025 4:20:13 am IST, Bandhan Pramanik bandhanpramanik06.foss@gmail.com wrote:
Please ignore the last email (I haven't replied to everyone). Also, here's the actual updated dmesg (the previous one was the old one): https://gist.github.com/BandhanPramanik/ddb0cb23eca03ca2ea43a1d832a16180/raw...
On Thu, Jun 26, 2025 at 4:16 AM Bandhan Pramanik bandhanpramanik06.foss@gmail.com wrote:
Hello Bjorn,
First of all, thanks a LOT for replying.
I have included the files in my previous GitHub Gist. Sharing the raw files for easier analysis.
lspci -vv: https://gist.github.com/BandhanPramanik/ddb0cb23eca03ca2ea43a1d832a16180/raw... dmesg: https://gist.github.com/BandhanPramanik/ddb0cb23eca03ca2ea43a1d832a16180/raw...
On a different note, I had to use pci=noaer, so that the ring buffer wouldn't get cleared that fast.
Regarding the ath10k thing, none of the fixes worked this time. Only irqpoll worked. I don't know if it's because of a disparity b/w GNOME and KDE (because my daily driver is Fedora 42), but I'm 300% sure that it's not just the Wi-Fi that's the issue here. It's most probably a lot of issues here, and the harder issues to fix are usually the ones closer to the hardware.
Anyway, if you get something, please let me know.
Bandhan
Just a small update: it's not the fix. Back to square 1.
On 26 June 2025 11:23:14 pm IST, Bandhan Pramanik bandhanpramanik06.foss@gmail.com wrote:
Hello everyone,
I think I found it. I used irqpoll and I didn't experience any hiccups with my mouse performance. But the Wi-Fi was still malfunctioning.
To linux-pci and linux-acpi:
It's an ath10k problem, sure, but there's something definitely problematic happening if, in the normal state, these Wi-Fi bugs hamper the touchpad movement.
To ath10k and linux-wireless:
I tried out "options ath10k_core rawmode = 0" along with "skip_otp=y' and the Wi-Fi seems to work perfectly as of now. It might be the fix, it might not be either. But I think there's something more important to ask: Are there any good resources/documentation on referring to what the different key-value pairs mean? Like, what's the exact documentation through which people arrive at "rawmode=0" or "skip_otp=y"?
Bandhan
linux-stable-mirror@lists.linaro.org
-
Bandhan Pramanik -
Bjorn Helgaas