This document describes my attemt to get Linux (Fedora 30) up and running in a sensible way on Hyperbook NH5/Clevo NH55RCQ.
That laptop has (at the time of purchase - May 2019) really nice specification, but due to positioning it as a "gaming laptop" the Linux-friendliness doesn't have a high priority. Although, it is possible to run it directly from a LiveUSB with Fedora 30, I have spent (definitely too) much time trying to solve the problems I encountered down the line. In hindsight, I could choose something more Linux-supported, but anyway, I created that list for other desperados to be up and running in several minutes instead of several dozen hours :).
There is a problem with getting HDMI output using standard Nouveau driver. Update. It seems to be fixed as of August 2021 - see below.
It's a complex issue. I split it into a few point.
It's deeply described in the issue I created.
Support for GeForce GTX 1650 (NV167/TU117) has been added in 5.2-rc1, but GeForce GTX 1660 Ti (NV168/TU116) hasn't.
kernel: nouveau 0000:01:00.0: enabling device (0106 -> 0107)
kernel: nouveau 0000:01:00.0: unknown chipset (168000a1)
kernel: nouveau: probe of 0000:01:00.0 failed with error -12
As a result the chip is not recognized. As a workaround it is possible to use a mode for 1650 with 1660 by adding nouveau.config=NvChipset=0x167 to GRUB_CMDLINE_LINUX in /etc/sysconfig/grub. However, it works with 5.2-rc1+.
Update. Starting with 5.3-RC1 TU116 is recognized and the aforementioned workaround is no longer needed. Though, it's still only the basic support for that card.
The HDMI output in NH5 1660 Ti is wired to the NVidia card. As a result it is required to do "reverse PRIME" to have the Intel card generate output to be displayed on a screen handled by the NVidia card. It works out-of-box with Wayland, but with Gnome 3 and LXQt on Xorg only a black background is visible with a moving mouse cursor. It's unclear whether it is an issue wtih Nouveau or Xorg/compose. It requires further investigation.
As a workaround a Mini DisplayPort output can be used. Another workaround is an usage of the official NVidia driver for Linux.
Btw, it should not be a problem with NH5 1650 as HDMI is connected there to the Intel card. However, there could be some issues trying to render content on the NVidia card and displaying it on the HDMI-connected screen.
Update 2021. With Fedora 34 (kernel 5.13.12 and Gnome 40.4) the monitor connected to HDMI works just fine also with Xorg (no manual setup required). Effectively, you can use 3 screens (1 built-in and 2 external) with a regular Nouveau driver. Btw, I haven't tested it for a while, so maybe it was already fixed in Fedora 33.
As it turned out, NH5 with 1660 Ti has a mDP port is connected to Intel. It's great as it is possible to use an external monitor while still having NVidia card disabled (via Nouveau and vgaswitcheroo). It is just enough to use a mDP -> HDMI adapter.
Initially, I have encountered a small issue with not very stable output on an external monitor. It got lost after every display mode change (or even calling xrandr). It turned out that mDP -> HDMI -> DVI combination may not work with some adapters/monitors. mDP adapter + HDMI-DVI cable works much better.
Starting with 5.4-RC4 systems hangs on the subsequent graphic settings (even calling xrandr after login is enought. Reported issues: #516.
I spent some time trying to narrow the scope using bisect. It narrowed the regression introduction period to "only" a few days (7-11 Aug) and "only" around 250 commits. After the discussion on the mailing list, with a help from Ilia Mirkin further bisecting pointed https://github.com/torvalds/linux/commit/0acf5676dc0ffe0683543a20d5ecbd112af5b8ee as a culprit. Later on it turned out that the problem had been already solved and with 5.5.0-rc2+ the problem doesn't occur and my TU116 works fine. The only small inconvenience is the need to used RC versions of the new kernel (e.g. for Fedora built in Koji) .
The booting process hangs for 60s+ on "Wait for Complete Device Initialization".
Blacklist the i2c_nvidia_gpu module by placing:
blacklist i2c_nvidia_gpu
in /etc/modprobe.d/blacklist_i2c-nvidia-gpu.conf.
Reported in the Fedora bugtracker.
As it took me a while, I post here a way how I found a reason to (potentially) help others struggling with similar issues.
Jun 14 11:14:06 foobar systemd[1]: Starting udev Wait for Complete Device Initialization...
...
Jun 14 11:14:12 foobar systemd[1]: systemd-rfkill.service: Succeeded.
Jun 14 11:14:12 foobar audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-rfkill comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? >
Jun 14 11:14:12 foobar kernel: kauditd_printk_skb: 42 callbacks suppressed
Jun 14 11:14:12 foobar kernel: audit: type=1131 audit(1560503652.402:64): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-rfkill comm="systemd" exe="/usr/lib/systemd/systemd" h>
Jun 14 11:15:07 foobar systemd-udevd[1095]: 24-0008: Worker [1171] processing SEQNUM=3730 is taking a long time
Jun 14 11:15:40 foobar systemd[1]: Started udev Wait for Complete Device Initialization.
systemd-analyze blame confirmed systemd-udev-settle.service as the main delay point.
I turned on debug logs in udev by adding udev_log="debug" in /etc/udev/udev.conf. With that I've got:
> $ journalctl -b -2 | grep 24-0008
Jun 14 12:44:48 foobar systemd-udevd[1089]: 24-0008: Device (SEQNUM=3683, ACTION=add) is queued
Jun 14 12:44:48 foobar systemd-udevd[1089]: 24-0008: sd-device-monitor: Passed 195 byte to netlink monitor
Jun 14 12:44:48 foobar systemd-udevd[1098]: 24-0008: Processing device (SEQNUM=3683, ACTION=add)
Jun 14 12:44:48 foobar systemd-udevd[1098]: 24-0008: IMPORT builtin 'hwdb' /usr/lib/udev/rules.d/50-udev-default.rules:14
Jun 14 12:44:48 foobar systemd-udevd[1098]: 24-0008: No entry found from hwdb.
Jun 14 12:44:48 foobar systemd-udevd[1098]: 24-0008: IMPORT builtin 'hwdb' fails: No data available
Jun 14 12:44:48 foobar systemd-udevd[1098]: 24-0008: RUN 'kmod load $env{MODALIAS}' /usr/lib/udev/rules.d/80-drivers.rules:5
Jun 14 12:45:48 foobar systemd-udevd[1089]: 24-0008: Worker [1098] processing SEQNUM=3683 is taking a long time
Jun 14 12:46:21 foobar systemd-udevd[1089]: 24-0008: Device (SEQNUM=3959, ACTION=bind) is queued
Jun 14 12:46:21 foobar systemd-udevd[1098]: 24-0008: Device (SEQNUM=3683, ACTION=add) processed
Jun 14 12:46:21 foobar systemd-udevd[1098]: 24-0008: sd-device-monitor: Passed 195 byte to netlink monitor
Jun 14 12:46:21 foobar systemd-udevd[1089]: 24-0008: sd-device-monitor: Passed 213 byte to netlink monitor
Jun 14 12:46:21 foobar systemd-udevd[1100]: 24-0008: Processing device (SEQNUM=3959, ACTION=bind)
Jun 14 12:46:21 foobar systemd-udevd[1100]: 24-0008: IMPORT builtin 'hwdb' /usr/lib/udev/rules.d/50-udev-default.rules:14
Jun 14 12:46:21 foobar systemd-udevd[1100]: 24-0008: No entry found from hwdb.
Jun 14 12:46:21 foobar systemd-udevd[1100]: 24-0008: IMPORT builtin 'hwdb' fails: No data available
Jun 14 12:46:21 foobar systemd-udevd[1100]: 24-0008: Device (SEQNUM=3959, ACTION=bind) processed
Jun 14 12:46:21 foobar systemd-udevd[1100]: 24-0008: sd-device-monitor: Passed 213 byte to netlink monitor
Jun 14 12:47:16 foobar kernel: ucsi_ccg 24-0008: failed to reset PPM!
Jun 14 12:47:16 foobar kernel: ucsi_ccg 24-0008: PPM init failed (-110)
And:
$ udevadm info /sys/bus/i2c/devices/24-0008
Successfully loaded SELinux database in 1.002ms, size on heap is 328K.
P: /devices/pci0000:00/0000:00:01.0/0000:01:00.3/i2c-24/24-0008
L: 0
E: DEVPATH=/devices/pci0000:00/0000:00:01.0/0000:01:00.3/i2c-24/24-0008
E: DRIVER=ucsi_ccg
E: MODALIAS=i2c:ccgx-ucsi
E: SUBSYSTEM=i2c
which suggested NVidia. Having more keywords I was able to find this thread related to similar Clevo-based laptop.
Blacklisting i2c_nvidia_gpu in fact removed the delay.
Local pings over 5GHz WiFi networks to that computer take over 100ms.
It seems to be realted to the Power Management feature. By disabling it manually:
sudo iwconfig wlp0s20f3 power off
the pings are back at the ~2ms level. It can be disabled permanently by putting default-wifi-powersave-off.conf in /etc/NetworkManager/conf.d/ with the following content:
# Disable powersave mode by default as it generates 100ms+ pings from localnetwork
# Possible values: 0 (use default), 1 (ignore/don't touch), 2 (disable), 3 (enable)
[connection]
wifi.powersave = 2
Please note that it may impact the power consumption when running on battery.
It was initially a big problem. Computer doesn't bring back after resume or keyword was not working or internal touchpad was disabled. However, with kernel 5.5-rc2+ which improved some other power managament issues with those NVidia graphic cards the problem disappeared. It wasn't able to get it failed after that with various configurations (with/out external monitor, with/out external keyboard, etc.). It hope there will be no regressions in the future.
Update 2020. There was a regression in kernel 5.7.6+, however, the problematic change was reverted in 5.7.12 (and also is not available in 5.8.0+).
The keyboard backlight is enabled by default. There is no way to disable it by default in the currently installed BIOS.
That kernel driver (built manually) disables the keyboard baclight on load, but it is impossible to bring it back (without powering off the computer). The driver doesn't seem to be maintained anymore.
There is also a driver from the System76 computer manufacturer which after some adaptation can be used to controll the keyboard backlight using the keyboard shortcuts. It would be nice to have it in Fedora as a kmod module. Update January 2020. I created a kmod version of this driver for Fedora. Available from the COPR repository.
kernel: pcieport 0000:00:1d.6: AER: Multiple Corrected error received: 0000:00:1d.6
kernel: pcieport 0000:00:1d.6: AER: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Transmitter ID)
kernel: pcieport 0000:00:1d.6: AER: device [8086:a336] error status/mask=00001000/00002000
kernel: pcieport 0000:00:1d.6: AER: [12] Timeout
The following error was occuring a few times a day when connected with the wireless network. However, coping GBs of files over sshfs with a 1Gbps direct ethernet connection it started to be logged 20-30 times per second, limiting effective transfer rate to ~100Mbps (the reduced speed might be an issue with a cable). With disabled advanced error reporting ("pci=noaer") errors are no longer printed and I had ~1Gbps with sshfs, but it only hides an underlying problem with hardware.
Add pci=noaer to GRUB_CMDLINE_LINUX in /etc/sysconfig/grub to disable Advanced Error Reporting.
Related issues: https://bugzilla.redhat.com/show_bug.cgi?id=1616364
As suggested in the related bug, with Kernel 5.5.rc4+ the following can be added to the kernel parameters:
pcie_aspm=off iommu=1 amd_iommu=on
$ sensors | grep nouveau -A4
nouveau-pci-0100
Adapter: PCI adapter
temp1: +511.0°C (high = +95.0°C, hyst = +3.0°C)
(crit = +105.0°C, hyst = +5.0°C)
(emerg = +135.0°C, hyst = +5.0°C)
A known issue/limitation.
There are errors in the system logs as follows:
kernel: iwlwifi 0000:00:14.3: BIOS contains WGDS but no WRDS
Reported: https://bugzilla.redhat.com/show_bug.cgi?id=1720324
Ocassionally there are the following errors in the system log:
kernel: ACPI BIOS Error (bug): AE_AML_PACKAGE_LIMIT, Index (0x0000000FF) is beyond end of object (length 0x11) (20190509/exoparg2-393)
kernel: ACPI Error: Aborting method \_SB.GINF due to previous error (AE_AML_PACKAGE_LIMIT) (20190509/psparse-529)
kernel: ACPI Error: Aborting method \_SB.GADR due to previous error (AE_AML_PACKAGE_LIMIT) (20190509/psparse-529)
kernel: ACPI Error: Aborting method \_SB.SGOV due to previous error (AE_AML_PACKAGE_LIMIT) (20190509/psparse-529)
kernel: ACPI Error: Aborting method \_SB.CGWR due to previous error (AE_AML_PACKAGE_LIMIT) (20190509/psparse-529)
kernel: ACPI Error: Aborting method \_SB.TBFP due to previous error (AE_AML_PACKAGE_LIMIT) (20190509/psparse-529)
kernel: ACPI Error: Aborting method \_SB.WMTF.WMTF due to previous error (AE_AML_PACKAGE_LIMIT) (20190509/psparse-529)
Might be related to: https://bugzilla.kernel.org/show_bug.cgi?id=195159
Update December 2019.. Suspend to RAM seems to work fine with kernel 5.5-rc2+.
The biggest (known) remaining problem is handing on resume from "suspend to RAM". Otherwise, the laptop works smoothly (at the time of writing :) ). I hope it will be durable enough to pay off :).
https://www.hyperbook.pl/ - a Polish company selling NH5 and other laptops for gamers and IT professionals - they agreed to check the laptop with Linux LiveUSB before a purchase - to check if it is possible to boot it with Linux (in hindsight, I should ask them for an external monitor :) )
https://system76.com/laptops - a Denver-based company selling powerful laptops (and desktops) tailor made for Linux, with own Linux distribution, Kernel drivers and firmware - they know a lot about hardware and care about Linux users