You are not logged in.
Hi,
my new Clevo N750WU laptop with Archlinux + Gnome freezes when Network Manager is running, so I have to reboot by pressing and holding down the power button.
This happens with all new kernels (from 4.19.xxx to the 4.20.7). The only working kernel is the 4.18.16 that now I have on.
It turns out to be an issue related to my wifi card Intel Corporation Wireless-AC 9260 (rev 29).
I reported this bug here: https://bugs.archlinux.org/task/60841 but currently nothing has been fixed.
Any idea is appreceated.
Cheers
Offline
I have the exact same laptop and have not experienced any problems when upgrading to the latest kernels. What output do you get from sudo lspci -v? You only need to include the section about the Network Controller.
EDIT:
Forgot to include that I also use Network Manager. However, I do not use GNOME.
Last edited by Rydberg95 (2019-02-12 16:09:48)
Offline
I remember now, I had a problem during the installation as well. The problem only showed itself when activating wifi,and, after consulting the forum, I managed to get WiFi working without the computer freezing. What I have to do is booting with the following kernel parameter:
intel_idle.max_cstate=4
What this does is preventing the processor from going into deeper sleep states. Why it has an impact on WiFi, I do not know. Worth mentioning is that I have not seen an impact on my battery life.
You can find the thread I created here:
https://bbs.archlinux.org/viewtopic.php?id=243307
I also would like to see this issue fixed, since it's clearly a bug, and what I'm using (and suggesting) is a workaround.
Offline
I have the exact same laptop and have not experienced any problems when upgrading to the latest kernels. What output do you get from sudo lspci -v? You only need to include the section about the Network Controller.
EDIT:
Forgot to include that I also use Network Manager. However, I do not use GNOME.
Thank you so much for your help!
This is sudo lspci -v
02:00.0 Network controller: Intel Corporation Wireless-AC 9260 (rev 29)
Subsystem: Intel Corporation Wireless-AC 9260
Flags: bus master, fast devsel, latency 0, IRQ 19
Memory at df000000 (64-bit, non-prefetchable) [size=16K]
Capabilities: [c8] Power Management version 3
Capabilities: [d0] MSI: Enable- Count=1/1 Maskable- 64bit+
Capabilities: [40] Express Endpoint, MSI 00
Capabilities: [80] MSI-X: Enable+ Count=16 Masked-
Capabilities: [100] Advanced Error Reporting
Capabilities: [14c] Latency Tolerance Reporting
Capabilities: [154] L1 PM Substates
Kernel driver in use: iwlwifi
Kernel modules: iwlwifi
this output is with 4.18. kernel, unless you wanted the newer 4.20.7
I'm checking your workaround about kernel parameter, I'll tell you as soon I get something
Thanks again
Last edited by Linux_i7 (2019-02-12 19:57:44)
Offline
it works!
I added your kernel parameter like this
sudo nano /boot/loader/entries/arch.conf
title Arch Linux
linux /vmlinuz-linux
initrd /initramfs-linux.img
options root=PARTUUID=4e7f9e91-2d78-44d2-8cbd-131200058b77 rw intel_idle.max_cstate=4
now Network Manager is working properly with
$ uname -r
4.20.7-arch1-1-ARCH
without flickering the screen and freezing my laptop
Thank you so much for your tip, that seems to be a workaround that can't solve this bug, but ... it's so useful because now I'm not stuck with an old kernel :-)
Offline
it works!
I added your kernel parameter like thissudo nano /boot/loader/entries/arch.conf
title Arch Linux
linux /vmlinuz-linux
initrd /initramfs-linux.img
options root=PARTUUID=4e7f9e91-2d78-44d2-8cbd-131200058b77 rw intel_idle.max_cstate=4now Network Manager is working properly with
$ uname -r
4.20.7-arch1-1-ARCHwithout flickering the screen and freezing my laptop
Thank you so much for your tip, that seems to be a workaround that can't solve this bug, but ... it's so useful because now I'm not stuck with an old kernel :-)
I'm glad I could help! Hopefully this issue will be patched. I will keep an eye on the bug report you created and hopefully it will lead to something.
Offline
I'm glad I could help! Hopefully this issue will be patched. I will keep an eye on the bug report you created and hopefully it will lead to something.
Bug reports for kernel issues on the arch bug tracker are not forwarded to upstream. It is expected those affected will work directly with upstream to resolve the issue.
I would suggest checking 5.0-rc6 if that is still affected bisect between 4.18 and 4.19 which has been suggested is where the issue was introduced.
Report the causal commit to the relevant bug tracker / mailing list with a CC to the author of the commit.
Last edited by loqs (2019-02-12 21:56:29)
Offline
Rydberg95 wrote:I'm glad I could help! Hopefully this issue will be patched. I will keep an eye on the bug report you created and hopefully it will lead to something.
Bug reports for kernel issues on the arch bug tracker are not forwarded to upstream. It is expected those affected will work directly with upstream to resolve the issue.
I would suggest checking 5.0-rc6 if that is still affected bisect between 4.18 and 4.19 which has been suggested is where the issue was introduced.
Report the causal commit to the relevant bug tracker / mailing list with a CC to the author of the commit.
Yes, bisecting, I did it, but turns out I'm not that good at it... I will give it a try one more time, who knows...
Offline
I will try my best to help with the bisection if you have issues with it.
Offline
I have also started the process of bisecting the kernel. My first takeaway is that building the kernel takes time...
Offline
I will try my best to help with the bisection if you have issues with it.
Since you offered your help, I summarized the process so far. The resource I used is Gentoos wiki (https://wiki.gentoo.org/wiki/Kernel_git-bisect), so if you have any feedback, I would gladly appreciate it. I do output the logs with pipes to a log file in the bisections steps, which I understand will be the final product.
My process:
• Cloning the kernel tree into /usr/src/:
git clone https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
• Started the bisection:
git bisect start
• Marked version 4.18.16 as good:
git bisect good v4.18.16
• Marked version 4.19.1 as bad:
git bisect bad v4.19.1
• Copied the config file from /usr/src/linux-4.18.16.arch1:
#Run in directory /usr/src/linux
cp ../linux-4.18.16.arch1/.config .
• Built the kernel:
make oldconfig
make -j4 && make modules_install && make install
After the kernel is done building, I will continue to follow the steps described in the Gentoo Wiki. I do have one question. The Arch Wiki's instruction on bisecting (https://wiki.archlinux.org/index.php/Bi … ler_kernel) states that i could build the kernel and only use the modules my system need. Is this a good idea, and do I replace make oldconfig with make localmodconfig?
Offline
I would suggest checking 5.0-rc6
I just checked the 5.0-rc6 mainline, but it still doesn't work. Now I'm looking for bisecting (if I will be able to)
Offline
The Arch Wiki https://wiki.archlinux.org/index.php/Bu … e_from_git states that "In order to bisect we are going to need to build a version of package from git. This can be accomplished by building the -git package from the AUR. "
That means that I have to download the linux-git package from the AUR, but here, though, I can only find an outdated kernel (4.18) https://aur.archlinux.org/packages/linux-git/.
So I'm wondering what git-kernel version do I have to download in order to build it, as suggested in arch wiki? And how do I "build" it? Is it just
git clone https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
like Rydberg posted above (thank you for that Rydberg)? I would prefer building new kernel not in src but in my Downloaded folder AND issueing
makepkg -i
?
Last edited by Linux_i7 (2019-02-13 18:28:09)
Offline
I've been bisecting the kernel and found the bad commit:
a99790bf5c7f3d68d8b01e015d3212a98ee7bd57 is the first bad commit
commit a99790bf5c7f3d68d8b01e015d3212a98ee7bd57
Author: Kai-Heng Feng <kai.heng.feng@canonical.com>
Date: Thu Jun 21 16:30:39 2018 +0800
r8169: Reinstate ASPM Support
On Intel platforms (Skylake and newer), ASPM support in r8169 is the
last missing puzzle to let CPU's Package C-State reaches PC8. Without
ASPM support, the CPU cannot reach beyond PC3. PC8 can save additional
~3W in comparison with PC3 on a Coffee Lake platform, Dell G3 3779.
This is based on the work from Chunhao Lin <hau@realtek.com>.
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
:040000 040000 87d4515c14f8eb8cf99b6f47f97ca4db700931c1 e542595c74609136a7094777afb10b83012f6643 M drivers
This seems very much like the right bad commit, considering the kernel parameter IMO prevents just this.
Now, can anyone provide me with assistance as to where I should submit this? In previous post, loqs mentioned that I should report the causal commit to the relevant bug tracker, and I'm uncertain as of where to start looking for the right one.
Offline
I emailed the author of the commit and got this reply.
From platforms I’ve seen, if ASPM on r8169 is disabled, the deepest Package C-State on Intel CPU will limit to PC3.
If the ASPM on r8169 is enabled, it can reach to PC8 when the display is on, and be able to reach PC10 when display is off.
So the issue seems to be a platform bug - deeper Package C state makes your system unstable.
Please contact the system vendor, the deepest Package C state can be reach should be set by BIOS.
Kai-Heng
Offline
"contact the system vendor" ??? Oh My GOD :-(
so turns out that Clevo laptops are not compatible with Linux kernels (all of them), therefore we have to switch to windows sooner or later? omg!!
Last edited by Linux_i7 (2019-02-14 19:50:27)
Offline
"contact the system vendor" ??? Oh My GOD :-(
so turns out that Clevo laptops are not compatible with Linux kernels (all of them), therefore we have to switch to windows sooner or later? omg!!
Well, if I understand correctly, the only thing the system vendor would patch is preventing the higher numbered C-states, which is the same thing the kernel parameter is doing. So no need to switch to Windows.
Offline
Thank you for doing the bisection. You could try the netdev@vger.kernel.org asking for a quirk to be added for your system preventing ASPM from being used in the r8169 driver.
Offline
Thank you for doing the bisection. You could try the netdev@vger.kernel.org asking for a quirk to be added for your system preventing ASPM from being used in the r8169 driver.
Sure, thank you. Just to be clear, am I right about preventing ASPM does essentially the same thing as using the intel_idle.max_ctate kernel parameter?
Offline
In essence yes, though the path that it takes there is roundabout. Disabling ASPM simply prevents the system from ever reaching these lower power states, but through the roundabout way of simply keeping a component powered that doesn't necessarily have to be kept powered (on normal systems, where enabling ASPM and the ability to reach lower states would be benefitial).
Offline
loqs wrote:Thank you for doing the bisection. You could try the netdev@vger.kernel.org asking for a quirk to be added for your system preventing ASPM from being used in the r8169 driver.
Sure, thank you. Just to be clear, am I right about preventing ASPM does essentially the same thing as using the intel_idle.max_ctate kernel parameter?
I believe so.
Offline
In essence yes, though the path that it takes there is roundabout. Disabling ASPM simply prevents the system from ever reaching these lower power states, but through the roundabout way of simply keeping a component powered that doesn't necessarily have to be kept powered (on normal systems, where enabling ASPM and the ability to reach lower states would be benefitial).
I see. Thank you for the explanation.
Offline
any update?
Offline
any update?
Offline