FS#55665 - [linux] RTL8192EE PCIe Wireless Network Adapter can't connect with intel_iommu enabled kernel
Attached to Project:
Arch Linux
Opened by Wind.Lee (zwindl) - Sunday, 17 September 2017, 23:48 GMT
Last edited by Doug Newgard (Scimmia) - Sunday, 01 October 2017, 15:10 GMT
Opened by Wind.Lee (zwindl) - Sunday, 17 September 2017, 23:48 GMT
Last edited by Doug Newgard (Scimmia) - Sunday, 01 October 2017, 15:10 GMT
|
Details
Description:
The RTL8192EE wifi card can't work properly with NetworkManager since kernel 4.13, it's gets stuck at 'configuring'. Here's the dmesg log https://ptpb.pw/dlJN and here's the journalctl log https://ptpb.pw/N9eT and I've tried compile myself with two different .config, one is from aur package linux-git(https://ptpb.pw/HF1g) which can run properly, wifi can connect on login, another is from official repo's linux package(https://ptpb.pw/7GuV) which can cause that issue. Additional info: * package version(s) linux 4.13.2-1 * config and/or log files etc. dmesg log: https://ptpb.pw/dlJN journalctl log: https://ptpb.pw/N9eT .config from linux-git: https://ptpb.pw/HF1g .config from archlinux's official linux package: https://ptpb.pw/7GuV Steps to reproduce: I reported to the kernel mailing-list fist, and tried to git bisect 4.13/4.12, but it's all pass when I was using linux-git's .config, and I shifted to official .config, it failed. |
This task depends upon
How exactily did you shift to the official config?
Going over the kernels you built:
4.12 with official 4.13 config good?
4.13 with official 4.13 config bad?
4.12 with linux-git config good?
4.13 with linux-git config good?
4.12 with official 4.13 config didn't test.
4.13 with official 4.13 config bad.
4.12 with linux-git config good.
4.13 with linux-git config good.
I'm testing the 4.12 with official 4.13 config. Report later.
enabled CONFIG_RTLWIFI_DEBUG which is not set in linux-git
If that is not the cause I would suggest diffing the two configs and merging the differences.
Make sure to diff the config after it has been processed by the 4.12 kernel so the third line references 4.12 not 4.13.
EDIT: Obviously, you were supposed to read my mind and know that I really meant the one in [testing]. :D
such as firmware supplying bad information to the kernel or bad interaction with another component that is using IOMMU.
You could investigate if upstream is aware of the issue and if upstream considers it a kernel bug.
Would hetfig consider reverting the change CONFIG_INTEL_IOMMU_DEFAULT_ON=y as it appears to have triggered this issue and
FS#55629?@loqs I didn't meet any freeze problem. seems OK for me.