Skip to content

Instantly share code, notes, and snippets.

Embed
What would you like to do?
Hyperbook NH5/Clevo NH55RCQ (post-)installation issues (and fixes) with Linux (Fedora 30)

Hyperbook NH5/Clevo NH55RCQ (post-)installation issues (and fixes) with Linux (Fedora 30)

Intro

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 :).

Major

No HDMI output on Nouveau driver - WORKAROUND

There is a problem with getting HDMI output using standard Nouveau driver.

It's a complex issue. I split it into a few point.

GeForce GTX 1660 Ti is not supported by Nouveau driver (as of Kernel 5.2) - WORKAROUND

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+.

Black screen on external monitor connected via HDMI - PARTIALLY + WORKAROUND

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.

Not stable output via Mini DisplayPort - SOLVED

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.

Long startup time - SOLVED

The booting process hangs for 60s+ on "Wait for Complete Device Initialization".

Solution

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.

More information

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.

Poor WiFi performance - SOLVED

Local pings over 5GHz WiFi networks to that computer take over 100ms.

Solution

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.

Laptop hangs after resuming from "suspend to RAM"

TODO

Minor

No control over keyboard backlight - WORK-IN-PROGRESS

The keyboard backlight is enabled by default. There is no way to disable it by default in the currently installed BIOS.

Workaround 1

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.

Workaround 2

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.

AER: Multiple Corrected error received: 0000:00:1d.6 - WORKAROUND

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.

Solution - workaround

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

Temperature of NVidia card reported as 511°C with Nouveau driver

$ 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.

BIOS contains WGDS but no WRDS in system logs

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

ACPI BIOS Error (bug): AE_AML_PACKAGE_LIMIT...

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

Summary

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 :).

Some related links

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.