https://wiki.archlinux.org/api.php?action=feedcontributions&user=Xythrez&feedformat=atomArchWiki - User contributions [en]2024-03-29T06:53:24ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Lm_sensors&diff=617643Lm sensors2020-06-01T19:53:58Z<p>Xythrez: Updated zenpower to match current package in AUR</p>
<hr />
<div>{{DISPLAYTITLE:lm_sensors}}<br />
[[Category:System monitors]]<br />
[[Category:CPU]]<br />
[[cs:Lm sensors]]<br />
[[de:Lm sensors]]<br />
[[es:Lm sensors]]<br />
[[ja:Lm sensors]]<br />
[[pt:Lm sensors]]<br />
[[ru:Lm sensors]]<br />
[[zh-hans:Lm sensors]]<br />
{{Related articles start}}<br />
{{Related|Fan speed control}}<br />
{{Related|hddtemp}}<br />
{{Related|monitorix}}<br />
{{Related articles end}}<br />
[http://lm-sensors.org/ lm_sensors] (Linux monitoring sensors) is a free and open-source application that provides tools and drivers for monitoring temperatures, voltage, and fans. This document explains how to install, configure, and use lm_sensors.<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{Pkg|lm_sensors}} package.<br />
<br />
{{Note|More documentation is at the [https://github.com/groeck/lm-sensors/tree/master/doc GitHub repository]. In the future these may be installed, see {{Bug|48354}}.}}<br />
<br />
== Setup ==<br />
<br />
Use ''sensors-detect'' as root to detect and generate a list of kernel modules:<br />
<br />
{{Warning|Do not use anything other than the default options (by just hitting {{ic|Enter}}), unless you know exactly what you are doing. See [[#Laptop screen issues after running sensors-detect]].}}<br />
<br />
# sensors-detect<br />
<br />
It will ask to probe for various hardware. The "safe" answers are the defaults, so just hitting {{ic|Enter}} to all the questions will generally not cause any problems. This will create the {{ic|/etc/conf.d/lm_sensors}} configuration file which is used by {{ic|lm_sensors.service}} to automatically load kernel modules on boot.<br />
<br />
When the detection is finished, a summary of the probes is presented.<br />
<br />
Example:<br />
<br />
{{hc|# sensors-detect|<nowiki><br />
This program will help you determine which kernel modules you need<br />
to load to use lm_sensors most effectively. It is generally safe<br />
and recommended to accept the default answers to all questions,<br />
unless you know what you're doing.<br />
<br />
Some south bridges, CPUs or memory controllers contain embedded sensors.<br />
Do you want to scan for them? This is totally safe. (YES/no): <br />
Module cpuid loaded successfully.<br />
Silicon Integrated Systems SIS5595... No<br />
VIA VT82C686 Integrated Sensors... No<br />
VIA VT8231 Integrated Sensors... No<br />
AMD K8 thermal sensors... No<br />
AMD Family 10h thermal sensors... No<br />
<br />
...<br />
<br />
Now follows a summary of the probes I have just done.<br />
Just press ENTER to continue: <br />
<br />
Driver `coretemp':<br />
* Chip `Intel digital thermal sensor' (confidence: 9)<br />
<br />
Driver `lm90':<br />
* Bus `SMBus nForce2 adapter at 4d00'<br />
Busdriver `i2c_nforce2', I2C address 0x4c<br />
Chip `Winbond W83L771AWG/ASG' (confidence: 6)<br />
<br />
Do you want to overwrite /etc/conf.d/lm_sensors? (YES/no): <br />
ln -s '/usr/lib/systemd/system/lm_sensors.service' '/etc/systemd/system/multi-user.target.wants/lm_sensors.service'<br />
Unloading i2c-dev... OK<br />
Unloading cpuid... OK<br />
</nowiki>}}<br />
<br />
{{Note|A systemd service is automatically enabled if users answer '''YES''' when asked about generating {{ic|/etc/conf.d/lm_sensors}}. Answering '''YES''' also automatically starts the service.}}<br />
<br />
== Running sensors ==<br />
<br />
Example running {{ic|sensors}}:<br />
<br />
{{hc|$ sensors|<nowiki><br />
coretemp-isa-0000<br />
Adapter: ISA adapter<br />
Core 0: +35.0°C (crit = +105.0°C)<br />
Core 1: +32.0°C (crit = +105.0°C)<br />
<br />
w83l771-i2c-0-4c<br />
Adapter: SMBus nForce2 adapter at 4d00<br />
temp1: +28.0°C (low = -40.0°C, high = +70.0°C)<br />
(crit = +85.0°C, hyst = +75.0°C)<br />
temp2: +37.4°C (low = -40.0°C, high = +70.0°C)<br />
(crit = +110.0°C, hyst = +100.0°C)<br />
</nowiki>}}<br />
<br />
=== Reading SPD values from memory modules (optional) ===<br />
<br />
To read the SPD timing values from memory modules, install the {{pkg|i2c-tools}} package. Once installed, load the {{ic|eeprom}} [[kernel module]].<br />
<br />
# modprobe eeprom<br />
<br />
Finally, view memory information with {{ic|decode-dimms}}.<br />
<br />
Here is partial output from one machine:<br />
<br />
{{hc|# decode-dimms|<nowiki><br />
Memory Serial Presence Detect Decoder<br />
By Philip Edelbrock, Christian Zuckschwerdt, Burkart Lingner,<br />
Jean Delvare, Trent Piepho and others<br />
<br />
<br />
Decoding EEPROM: /sys/bus/i2c/drivers/eeprom/0-0050<br />
Guessing DIMM is in bank 1<br />
<br />
---=== SPD EEPROM Information ===---<br />
EEPROM CRC of bytes 0-116 OK (0x583F)<br />
# of bytes written to SDRAM EEPROM 176<br />
Total number of bytes in EEPROM 512<br />
Fundamental Memory type DDR3 SDRAM<br />
Module Type UDIMM<br />
<br />
---=== Memory Characteristics ===---<br />
Fine time base 2.500 ps<br />
Medium time base 0.125 ns<br />
Maximum module speed 1066MHz (PC3-8533)<br />
Size 2048 MB<br />
Banks x Rows x Columns x Bits 8 x 14 x 10 x 64<br />
Ranks 2<br />
SDRAM Device Width 8 bits<br />
tCL-tRCD-tRP-tRAS 7-7-7-33<br />
Supported CAS Latencies (tCL) 8T, 7T, 6T, 5T<br />
<br />
---=== Timing Parameters ===---<br />
Minimum Write Recovery time (tWR) 15.000 ns<br />
Minimum Row Active to Row Active Delay (tRRD) 7.500 ns<br />
Minimum Active to Auto-Refresh Delay (tRC) 49.500 ns<br />
Minimum Recovery Delay (tRFC) 110.000 ns<br />
Minimum Write to Read CMD Delay (tWTR) 7.500 ns<br />
Minimum Read to Pre-charge CMD Delay (tRTP) 7.500 ns<br />
Minimum Four Activate Window Delay (tFAW) 30.000 ns<br />
<br />
---=== Optional Features ===---<br />
Operable voltages 1.5V<br />
RZQ/6 supported? Yes<br />
RZQ/7 supported? Yes<br />
DLL-Off Mode supported? No<br />
Operating temperature range 0-85C<br />
Refresh Rate in extended temp range 1X<br />
Auto Self-Refresh? Yes<br />
On-Die Thermal Sensor readout? No<br />
Partial Array Self-Refresh? No<br />
Thermal Sensor Accuracy Not implemented<br />
SDRAM Device Type Standard Monolithic<br />
<br />
---=== Physical Characteristics ===---<br />
Module Height (mm) 15<br />
Module Thickness (mm) 1 front, 1 back<br />
Module Width (mm) 133.5<br />
Module Reference Card B<br />
<br />
---=== Manufacturer Data ===---<br />
Module Manufacturer Invalid<br />
Manufacturing Location Code 0x02<br />
Part Number OCZ3G1600LV2G <br />
<br />
...<br />
</nowiki>}}<br />
<br />
== Using sensor data ==<br />
<br />
=== Graphical front-ends ===<br />
<br />
There are a variety of front-ends for sensors data.<br />
<br />
* {{App|psensor|GTK application for monitoring hardware sensors, including temperatures and fan speeds. Monitors motherboard and CPU (using lm-sensors), Nvidia GPUs (using XNVCtrl), and harddisks (using [[hddtemp]] or libatasmart).|https://wpitchoune.net/psensor/|{{Pkg|psensor}}}}<br />
* {{App|xsensors|X11 interface to lm_sensors.|http://linuxhardware.org/xsensors/|{{Pkg|xsensors}}}}<br />
<br />
For specific [[Desktop environments]]:<br />
<br />
* {{App|Freon (GNOME Shell extension)|Extension for displaying CPU temperature, disk temperature, video card temperature , voltage and fan RPM in [[GNOME]] Shell.|https://github.com/UshakovVasilii/gnome-shell-extension-freon|{{AUR|gnome-shell-extension-freon}}}}<br />
* {{App|GNOME Sensors Applet|Applet for the [[GNOME]] Panel to display readings from hardware sensors, including CPU temperature, fan speeds and voltage readings.|http://sensors-applet.sourceforge.net/|{{Pkg|sensors-applet}}}}<br />
* {{App|lm-sensors (LXPanel plugin)|Monitor temperature/voltages/fan speeds in [[LXDE]] through lm-sensors.|http://danamlund.dk/sensors_lxpanel_plugin/|{{AUR|sensors-lxpanel-plugin}}}}<br />
* {{App|MATE Sensors Applet|Display readings from hardware sensors in your [[MATE]] panel.|https://github.com/mate-desktop/mate-sensors-applet|{{Pkg|mate-sensors-applet}}}}<br />
* {{App|Sensors (Xfce4 panel plugin)|Hardware sensors plugin for the [[Xfce]] panel.|http://goodies.xfce.org/projects/panel-plugins/xfce4-sensors-plugin|{{Pkg|xfce4-sensors-plugin}}}}<br />
* {{App|Thermal Monitor (Plasma 5 applet)|[[KDE]] Plasma applet for monitoring CPU, GPU and other available temperature sensors.|https://github.com/kotelnik/plasma-applet-thermal-monitor|{{AUR|plasma5-applets-thermal-monitor-git}}}}<br />
<br />
=== sensord ===<br />
<br />
There is an optional daemon called ''sensord'' (included with the {{Pkg|lm_sensors}} package) which can log data to a round robin database (rrd) and later visualize graphically. See the {{man|8|sensord}} man page for details.<br />
<br />
== Tips and tricks ==<br />
<br />
=== Adjusting values ===<br />
<br />
In some cases, the data displayed might be incorrect or users may wish to rename the output. Use cases include:<br />
<br />
* Incorrect temperature values due to a wrong offset (i.e. temps are reported 20 °C higher than actual).<br />
* Users wish to rename the output of some sensors.<br />
* The cores might be displayed in an incorrect order.<br />
<br />
All of the above (and more) can be adjusted by overriding the package provides settings in {{ic|/etc/sensors3.conf}} by creating {{ic|/etc/sensors.d/''foo''}} wherein any number of tweaks will override the default values. It is recommended to rename 'foo' to the motherboard brand and model but this naming nomenclature is optional.<br />
<br />
{{Note|Do not edit {{ic|/etc/sensors3.conf}} directly since package updates will overwrite any changes thus losing them.}}<br />
<br />
==== Example 1. Adjusting temperature offsets ====<br />
<br />
This is a real example on a Zotac ION-ITX-A-U motherboard. The coretemp values are off by 20 °C (too high) and are adjusted down to Intel specs.<br />
<br />
{{hc|$ sensors|<nowiki><br />
coretemp-isa-0000<br />
Adapter: ISA adapter<br />
Core 0: +57.0°C (crit = +125.0°C)<br />
Core 1: +55.0°C (crit = +125.0°C)<br />
...<br />
</nowiki>}}<br />
<br />
Run {{ic|sensors}} with the {{ic|-u}} switch to see what options are available for each physical chip (raw mode):<br />
<br />
{{hc|$ sensors -u|<nowiki><br />
coretemp-isa-0000<br />
Adapter: ISA adapter<br />
Core 0:<br />
temp2_input: 57.000<br />
temp2_crit: 125.000<br />
temp2_crit_alarm: 0.000<br />
Core 1:<br />
temp3_input: 55.000<br />
temp3_crit: 125.000<br />
temp3_crit_alarm: 0.000<br />
...<br />
</nowiki>}}<br />
<br />
Create the following file overriding the default values:<br />
<br />
{{hc|/etc/sensors.d/Zotac-IONITX-A-U|<nowiki><br />
chip "coretemp-isa-0000"<br />
label temp2 "Core 0"<br />
compute temp2 @-20,@-20<br />
<br />
label temp3 "Core 1"<br />
compute temp3 @-20,@-20<br />
</nowiki>}}<br />
<br />
Now invoking {{ic|sensors}} shows the adjust values:<br />
<br />
{{hc|$ sensors|<nowiki><br />
coretemp-isa-0000<br />
Adapter: ISA adapter<br />
Core 0: +37.0°C (crit = +105.0°C)<br />
Core 1: +35.0°C (crit = +105.0°C)<br />
...<br />
</nowiki>}}<br />
<br />
==== Example 2. Renaming labels ====<br />
<br />
This is a real example on an Asus A7M266. The user wishes more verbose names for the temperature labels {{ic|temp1}} and {{ic|temp2}}:<br />
<br />
{{hc|$ sensors|<nowiki><br />
as99127f-i2c-0-2d<br />
Adapter: SMBus Via Pro adapter at e800<br />
...<br />
temp1: +35.0°C (high = +0.0°C, hyst = -128.0°C)<br />
temp2: +47.5°C (high = +100.0°C, hyst = +75.0°C)<br />
...<br />
</nowiki>}}<br />
<br />
Create the following file to override the default values:<br />
<br />
{{hc|/etc/sensors.d/Asus_A7M266|<nowiki><br />
chip "as99127f-*"<br />
label temp1 "Mobo Temp"<br />
label temp2 "CPU0 Temp"<br />
</nowiki>}}<br />
<br />
Now invoking {{ic|sensors}} shows the adjust values:<br />
<br />
{{hc|$ sensors|<nowiki><br />
as99127f-i2c-0-2d<br />
Adapter: SMBus Via Pro adapter at e800<br />
...<br />
Mobo Temp: +35.0°C (high = +0.0°C, hyst = -128.0°C)<br />
CPU0 Temp: +47.5°C (high = +100.0°C, hyst = +75.0°C)<br />
...<br />
</nowiki>}}<br />
<br />
==== Example 3. Renumbering cores for multi-CPU systems ====<br />
<br />
This is a real example on an HP Z600 workstation with dual Xeons. The actual numbering of physical cores is incorrect: numbered 0, 1, 9, 10 which is repeated into the second CPU. Most users expect the core temperatures to report out in sequential order, i.e. 0,1,2,3,4,5,6,7.<br />
<br />
{{hc|$ sensors|<nowiki><br />
coretemp-isa-0000<br />
Adapter: ISA adapter<br />
Core 0: +65.0°C (high = +85.0°C, crit = +95.0°C)<br />
Core 1: +65.0°C (high = +85.0°C, crit = +95.0°C)<br />
Core 9: +66.0°C (high = +85.0°C, crit = +95.0°C)<br />
Core 10: +66.0°C (high = +85.0°C, crit = +95.0°C)<br />
<br />
coretemp-isa-0004<br />
Adapter: ISA adapter<br />
Core 0: +54.0°C (high = +85.0°C, crit = +95.0°C)<br />
Core 1: +56.0°C (high = +85.0°C, crit = +95.0°C)<br />
Core 9: +60.0°C (high = +85.0°C, crit = +95.0°C)<br />
Core 10: +61.0°C (high = +85.0°C, crit = +95.0°C)<br />
...<br />
</nowiki>}}<br />
<br />
Again, run {{ic|sensors}} with the {{ic|-u}} switch to see what options are available for each physical chip:<br />
<br />
{{hc|$ sensors -u coretemp-isa-0000|<nowiki><br />
coretemp-isa-0000<br />
Adapter: ISA adapter<br />
Core 0:<br />
temp2_input: 61.000<br />
temp2_max: 85.000<br />
temp2_crit: 95.000<br />
temp2_crit_alarm: 0.000<br />
Core 1:<br />
temp3_input: 61.000<br />
temp3_max: 85.000<br />
temp3_crit: 95.000<br />
temp3_crit_alarm: 0.000<br />
Core 9:<br />
temp11_input: 62.000<br />
temp11_max: 85.000<br />
temp11_crit: 95.000<br />
Core 10:<br />
temp12_input: 63.000<br />
temp12_max: 85.000<br />
temp12_crit: 95.000<br />
</nowiki>}}<br />
<br />
{{hc|$ sensors -u coretemp-isa-0004|<nowiki><br />
coretemp-isa-0004<br />
Adapter: ISA adapter<br />
Core 0:<br />
temp2_input: 53.000<br />
temp2_max: 85.000<br />
temp2_crit: 95.000<br />
temp2_crit_alarm: 0.000<br />
Core 1:<br />
temp3_input: 54.000<br />
temp3_max: 85.000<br />
temp3_crit: 95.000<br />
temp3_crit_alarm: 0.000<br />
Core 9:<br />
temp11_input: 59.000<br />
temp11_max: 85.000<br />
temp11_crit: 95.000<br />
Core 10:<br />
temp12_input: 59.000<br />
temp12_max: 85.000<br />
temp12_crit: 95.000<br />
...<br />
</nowiki>}}<br />
<br />
Create the following file overriding the default values:<br />
<br />
{{hc|/etc/sensors.d/HP_Z600|<nowiki><br />
chip "coretemp-isa-0000"<br />
label temp2 "Core 0"<br />
label temp3 "Core 1"<br />
label temp11 "Core 2"<br />
label temp12 "Core 3"<br />
<br />
chip "coretemp-isa-0004"<br />
label temp2 "Core 4"<br />
label temp3 "Core 5"<br />
label temp11 "Core 6"<br />
label temp12 "Core 7"</nowiki>}}<br />
<br />
Now invoking {{ic|sensors}} shows the adjust values:<br />
<br />
{{hc|$ sensors|<nowiki><br />
coretemp-isa-0000<br />
Adapter: ISA adapter<br />
Core0: +64.0°C (high = +85.0°C, crit = +95.0°C)<br />
Core1: +63.0°C (high = +85.0°C, crit = +95.0°C)<br />
Core2: +65.0°C (high = +85.0°C, crit = +95.0°C)<br />
Core3: +66.0°C (high = +85.0°C, crit = +95.0°C)<br />
<br />
coretemp-isa-0004<br />
Adapter: ISA adapter<br />
Core4: +53.0°C (high = +85.0°C, crit = +95.0°C)<br />
Core5: +54.0°C (high = +85.0°C, crit = +95.0°C)<br />
Core6: +59.0°C (high = +85.0°C, crit = +95.0°C)<br />
Core7: +60.0°C (high = +85.0°C, crit = +95.0°C)<br />
...<br />
</nowiki>}}<br />
<br />
=== Automatic lm_sensors deployment ===<br />
<br />
Users wishing to deploy lm_sensors on multiple machines can use the following to accept the defaults to all questions:<br />
<br />
# sensors-detect --auto<br />
<br />
== Troubleshooting ==<br />
<br />
=== K10Temp module ===<br />
<br />
Some K10 processors have issues with their temperature sensor. From the kernel documentation ({{ic|linux-&lt;version&gt;/Documentation/hwmon/k10temp}}):<br />
<br />
:''All these processors have a sensor, but on those for Socket F or AM2+, the sensor may return inconsistent values (erratum 319). The driver will refuse to load on these revisions unless users specify the {{ic|1=force=1}} module parameter.''<br />
<br />
:''Due to technical reasons, the driver can detect only the mainboard's socket type, not the processor's actual capabilities. Therefore, users of an AM3 processor on an AM2+ mainboard, can safely use the {{ic|1=force=1}} parameter.''<br />
<br />
On affected machines the module will report "unreliable CPU thermal sensor; monitoring disabled". To force monitoring anyway, you can run the following:<br />
<br />
# rmmod k10temp<br />
# modprobe k10temp force=1<br />
<br />
Confirm that the sensor is in fact valid and reliable. If it is, can edit {{ic|/etc/modprobe.d/k10temp.conf}} and add:<br />
<br />
options k10temp force=1<br />
<br />
This will allow the module to load at boot.<br />
<br />
=== Asus B450/X399/X470/A320M-K/A320M-K-BR motherboards with AM4 Socket ===<br />
<br />
Some recent Asus motherboards use a ITE IT8665E (B450/X399/X470) / IT8655E (A320M-K/A320M-K-BR) chip, accessing the temperature, fan and voltage sensors may require the {{ic|asus-wmi-sensors}} module. [[Install]] {{AUR|asus-wmi-sensors-dkms-git}} and load the {{ic|asus-wmi-sensors}} [[kernel module]], the module uses the UEFI interface and may require a BIOS update on some boards [https://github.com/electrified/asus-wmi-sensors#supported-hardware].<br />
<br />
Alternatively, the {{ic|it87}} module reads the values from the chip directly, install {{AUR|it87-dkms-git}} and load the {{ic|it87}} [[kernel module]].<br />
<br />
=== Asus Z97/Z170/X570 motherboards ===<br />
<br />
With some recent Asus motherboards, fan and voltage sensor access may require the {{ic|nct6775}} [[kernel module]] to be loaded.<br />
<br />
Additionally, add to the kernel boot parameters:<br />
<br />
acpi_enforce_resources=lax<br />
<br />
=== Gigabyte B250/Z370/B450M motherboards ===<br />
<br />
Some Gigabyte motherboards use the ITE IT8686E chip, which is not supported by the it87 kernel driver, as of May 2019 [https://www.kernel.org/doc/html/latest/hwmon/it87.html]. However, it is supported by the upstream version of the kernel driver [https://github.com/bbqlinux/it87/blob/master/it87.c#L24]. The [[DKMS]] variant is contained in {{AUR|it87-dkms-git}}. As with [[#Asus Z97/Z170/X570 motherboards]], a [[kernel parameter]] is required before attempting to install the module:<br />
<br />
acpi_enforce_resources=lax<br />
<br />
Furthermore, supply the id of the chip when loading the module as follows:<br />
<br />
# modprobe it87 force_id 0x8686<br />
<br />
Or you can [[Kernel_modules|load the module]] during boot process by creating the following two files:<br />
<br />
{{hc|/etc/modules-load.d/it87.conf|<br />
it87<br />
}}<br />
<br />
{{hc|/etc/modprobe.d/it87.conf|<nowiki><br />
options it87 force_id=0x8686<br />
</nowiki>}}<br />
<br />
Once the module is loaded you can use the ''sensors'' tool to probe the chip.<br />
Now you can also use [[fancontrol]] to control the speed step of your case fan. <br />
<br />
Optionally installation of {{AUR|zenpower-dkms}} may allow greater fine tuning of the motherboard's cooling system. However, it does disable the default k10temp module.<br />
<br />
=== Gigabyte GA-J1900N-D3V ===<br />
<br />
This motherboard uses the ITE IT8620E chip (useful also to read voltages, mainboard temp, fan speed). As of October 2014, lm_sensors has no driver support for chip ITE IT8620E [https://hwmon.wiki.kernel.org/device_support_status_g_i] [http://comments.gmane.org/gmane.linux.drivers.sensors/35168]. lm_sensors developers had a report that the chip is somewhat compatible with the IT8728F for the hardware monitoring part. However, as of August 2016, [https://www.kernel.org/doc/html/latest/hwmon/it87.html] lists the IT8620E as supported.<br />
<br />
You can load the module at runtime with modprobe:<br />
<br />
$ modprobe it87 force_id=0x8728<br />
<br />
Or you can [[Kernel modules|load the modules]] during boot process by creating the following two files:<br />
<br />
{{hc|/etc/modules-load.d/it87.conf|2=<br />
it87<br />
}}<br />
<br />
{{hc|/etc/modprobe.d/it87.conf|2=<br />
options it87 force_id=0x8603<br />
}}<br />
<br />
Once the module is loaded you can use the ''sensors'' tool to probe the chip.<br />
<br />
Now you can also use [[fancontrol]] to control the speedsteps of your case fan.<br />
<br />
=== Laptop screen issues after running sensors-detect ===<br />
<br />
This is caused by lm-sensors messing with the Vcom values of the screen while probing for sensors. It has been discussed and solved at the forums already: https://bbs.archlinux.org/viewtopic.php?id=193048. However, make sure to read through the thread carefully before running any of the suggested commands.</div>Xythrezhttps://wiki.archlinux.org/index.php?title=Ryzen&diff=615049Ryzen2020-05-22T17:44:54Z<p>Xythrez: Fixed link to lm_sensors</p>
<hr />
<div>[[Category:CPU]]<br />
[[ja:Ryzen]]<br />
{{Related articles start}}<br />
{{Related|Improving performance}}<br />
{{Related|Improving performance/Boot process}}<br />
{{Related|Kernel}}<br />
{{Related|Microcode}}<br />
{{Related articles end}}<br />
<br />
=== Enable microcode support ===<br />
<br />
[[Install]] the {{Pkg|amd-ucode}} package to enable microcode updates and enable it with the help of the [[Microcode]] page. These updates provide bug fixes that can be critical to the stability of your system. It is '''highly recommended''' to use it despite it being proprietary.<br />
<br />
== Tweaking Ryzen ==<br />
<br />
=== Power/Temperature Monitoring ===<br />
<br />
{{Pkg|lm_sensors}} should be able to monitor temperatures out of the box. However, for more detailed information such as power consumption and voltage, {{AUR|zenpower-dkms}} is needed. For GUI based monitoring tools, use {{AUR|zenmonitor}}. <br />
<br />
=== Power managing ===<br />
<br />
[https://github.com/FlyGoat/RyzenAdj RyzenAdj]|| {{AUR|ryzenadj-git}} (CLI) is a tool created by [https://github.com/FlyGoat FlyGoat] to adjust power management settings for Ryzen processors using a terminal emulator.<br />
<br />
=== Overclocking ===<br />
<br />
[https://github.com/r4m0n/ZenStates-Linux/ ZenStates-Linux] (CLI) is a tool made by [https://github.com/r4m0n r4m0n] to adjust the clock speed and voltage. A detailed example was given in [https://forum.level1techs.com/t/overclock-your-ryzen-cpu-from-linux/126025 Level1Techs]' forums by ''catsay'' for you to understand it.<br />
<br />
== Compiling a kernel ==<br />
<br />
See [[Gentoo:Ryzen#Kernel]] on enabling Ryzen support.<br />
<br />
== Troubleshooting ==<br />
<br />
=== Random reboots ===<br />
<br />
See [[Gentoo:Ryzen#Random_reboots_with_mce_events]] if you are experiencing random reboots.<br />
<br />
=== Screen-tearing (APU) ===<br />
<br />
If you are using [[Xorg]] and are experiencing screen-tearing, enabling the {{ic|"TearFree"}} option will fix the problem.<br />
<br />
{{hc|/etc/X11/xorg.conf.d/20-amdgpu.conf|<br />
Section "Device"<br />
Identifier "AMD"<br />
Driver "amdgpu"<br />
Option "TearFree" "true"<br />
EndSection<br />
}}<br />
<br />
{{Note| {{ic|"TearFree"}} is '''not''' Vsync.}}<br />
<br />
=== Soft lock freezing ===<br />
<br />
Some laptops with Ryzen CPUs such as the HP Envy x360 15-bq100na may experience CPU soft locks which result in a frozen system. These can be avoided with the "idle=nomwait" boot option.<br />
<br />
== See also ==<br />
<br />
* [[Gentoo:Ryzen]]</div>Xythrezhttps://wiki.archlinux.org/index.php?title=Ryzen&diff=615047Ryzen2020-05-22T17:40:32Z<p>Xythrez: Removed reference to lm-sensors in power managing after adding section on Power/Temperature Monitoring</p>
<hr />
<div>[[Category:CPU]]<br />
[[ja:Ryzen]]<br />
{{Related articles start}}<br />
{{Related|Improving performance}}<br />
{{Related|Improving performance/Boot process}}<br />
{{Related|Kernel}}<br />
{{Related|Microcode}}<br />
{{Related articles end}}<br />
<br />
=== Enable microcode support ===<br />
<br />
[[Install]] the {{Pkg|amd-ucode}} package to enable microcode updates and enable it with the help of the [[Microcode]] page. These updates provide bug fixes that can be critical to the stability of your system. It is '''highly recommended''' to use it despite it being proprietary.<br />
<br />
== Tweaking Ryzen ==<br />
<br />
=== Power/Temperature Monitoring ===<br />
<br />
{{Pkg|lm-sensors}} should be able to monitor temperatures out of the box. However, for more detailed information such as power consumption and voltage, {{AUR|zenpower-dkms}} is needed. For GUI based monitoring tools, use {{AUR|zenmonitor}}. <br />
<br />
=== Power managing ===<br />
<br />
[https://github.com/FlyGoat/RyzenAdj RyzenAdj]|| {{AUR|ryzenadj-git}} (CLI) is a tool created by [https://github.com/FlyGoat FlyGoat] to adjust power management settings for Ryzen processors using a terminal emulator.<br />
<br />
=== Overclocking ===<br />
<br />
[https://github.com/r4m0n/ZenStates-Linux/ ZenStates-Linux] (CLI) is a tool made by [https://github.com/r4m0n r4m0n] to adjust the clock speed and voltage. A detailed example was given in [https://forum.level1techs.com/t/overclock-your-ryzen-cpu-from-linux/126025 Level1Techs]' forums by ''catsay'' for you to understand it.<br />
<br />
== Compiling a kernel ==<br />
<br />
See [[Gentoo:Ryzen#Kernel]] on enabling Ryzen support.<br />
<br />
== Troubleshooting ==<br />
<br />
=== Random reboots ===<br />
<br />
See [[Gentoo:Ryzen#Random_reboots_with_mce_events]] if you are experiencing random reboots.<br />
<br />
=== Screen-tearing (APU) ===<br />
<br />
If you are using [[Xorg]] and are experiencing screen-tearing, enabling the {{ic|"TearFree"}} option will fix the problem.<br />
<br />
{{hc|/etc/X11/xorg.conf.d/20-amdgpu.conf|<br />
Section "Device"<br />
Identifier "AMD"<br />
Driver "amdgpu"<br />
Option "TearFree" "true"<br />
EndSection<br />
}}<br />
<br />
{{Note| {{ic|"TearFree"}} is '''not''' Vsync.}}<br />
<br />
=== Soft lock freezing ===<br />
<br />
Some laptops with Ryzen CPUs such as the HP Envy x360 15-bq100na may experience CPU soft locks which result in a frozen system. These can be avoided with the "idle=nomwait" boot option.<br />
<br />
== See also ==<br />
<br />
* [[Gentoo:Ryzen]]</div>Xythrezhttps://wiki.archlinux.org/index.php?title=Ryzen&diff=615046Ryzen2020-05-22T17:37:47Z<p>Xythrez: Added section for power/temperature monitoring tools</p>
<hr />
<div>[[Category:CPU]]<br />
[[ja:Ryzen]]<br />
{{Related articles start}}<br />
{{Related|Improving performance}}<br />
{{Related|Improving performance/Boot process}}<br />
{{Related|Kernel}}<br />
{{Related|Microcode}}<br />
{{Related articles end}}<br />
<br />
=== Enable microcode support ===<br />
<br />
[[Install]] the {{Pkg|amd-ucode}} package to enable microcode updates and enable it with the help of the [[Microcode]] page. These updates provide bug fixes that can be critical to the stability of your system. It is '''highly recommended''' to use it despite it being proprietary.<br />
<br />
== Tweaking Ryzen ==<br />
<br />
=== Power/Temperature Monitoring ===<br />
<br />
{{Pkg|lm-sensors}} should be able to monitor temperatures out of the box. However, for more detailed information such as power consumption and voltage, {{AUR|zenpower-dkms}} is needed. For GUI based monitoring tools, use {{AUR|zenmonitor}}. <br />
<br />
=== Power managing ===<br />
<br />
[https://github.com/FlyGoat/RyzenAdj RyzenAdj]|| {{AUR|ryzenadj-git}} (CLI) is a tool created by [https://github.com/FlyGoat FlyGoat] to adjust power management settings for Ryzen processors using a terminal emulator.<br />
<br />
{{Tip|You can use {{Pkg|lm_sensors}} to monitor the temperature of your processor.}}<br />
<br />
=== Overclocking ===<br />
<br />
[https://github.com/r4m0n/ZenStates-Linux/ ZenStates-Linux] (CLI) is a tool made by [https://github.com/r4m0n r4m0n] to adjust the clock speed and voltage. A detailed example was given in [https://forum.level1techs.com/t/overclock-your-ryzen-cpu-from-linux/126025 Level1Techs]' forums by ''catsay'' for you to understand it.<br />
<br />
== Compiling a kernel ==<br />
<br />
See [[Gentoo:Ryzen#Kernel]] on enabling Ryzen support.<br />
<br />
== Troubleshooting ==<br />
<br />
=== Random reboots ===<br />
<br />
See [[Gentoo:Ryzen#Random_reboots_with_mce_events]] if you are experiencing random reboots.<br />
<br />
=== Screen-tearing (APU) ===<br />
<br />
If you are using [[Xorg]] and are experiencing screen-tearing, enabling the {{ic|"TearFree"}} option will fix the problem.<br />
<br />
{{hc|/etc/X11/xorg.conf.d/20-amdgpu.conf|<br />
Section "Device"<br />
Identifier "AMD"<br />
Driver "amdgpu"<br />
Option "TearFree" "true"<br />
EndSection<br />
}}<br />
<br />
{{Note| {{ic|"TearFree"}} is '''not''' Vsync.}}<br />
<br />
=== Soft lock freezing ===<br />
<br />
Some laptops with Ryzen CPUs such as the HP Envy x360 15-bq100na may experience CPU soft locks which result in a frozen system. These can be avoided with the "idle=nomwait" boot option.<br />
<br />
== See also ==<br />
<br />
* [[Gentoo:Ryzen]]</div>Xythrezhttps://wiki.archlinux.org/index.php?title=Dell_XPS_15_(9570)&diff=576200Dell XPS 15 (9570)2019-06-23T08:15:20Z<p>Xythrez: Optimus: added simpler solution to fixing NVIDIA card pm</p>
<hr />
<div>[[Category:Dell]]<br />
[[ja:Dell XPS 15 (9570)]]<br />
{{Note|This page far from completed. Some not mentioned items could be same as [[XPS 15 9560]]. Most of it also applies to the Precision 5530}}<br />
<br />
{| class="wikitable" style="float: right;"<br />
| '''Device/Functionality''' || '''Status'''<br />
|-<br />
| [[#Suspend|Suspend]] || {{G|Working}}<br />
|-<br />
| [[#Hibernate|Hibernate]] || {{G|Working}}<br />
|-<br />
| [[#Graphics|Integrated Graphics]] || {{G|Working}}<br />
|-<br />
| [[#Graphics|Discrete Nvidia Graphics]] || {{Y|Modify}}<br />
|-<br />
| [[#Wifi_and_Bluetooth|Wifi]] || {{G|Working}}<br />
|-<br />
| [[#Wifi_and_Bluetooth|Bluetooth]] || {{G|Working}}<br />
|-<br />
| [[#Wifi_and_Bluetooth|rfkill]] || {{G|Working}}<br />
|-<br />
| Audio || {{G|Working}}<br />
|-<br />
| [[#Touchpad and Touchscreen|Touchpad]] || {{G|Working}}<br />
|-<br />
| [[#Touchpad and Touchscreen|Touchscreen]] || {{G|Working}}<br />
|-<br />
| Webcam || {{G|Working}}<br />
|-<br />
| Card Reader || {{G|Working}}<br />
|-<br />
| Function/Multimedia Keys || {{G|Working}}<br />
|-<br />
| [[#Power Management|Power Management]] || {{G|Working}}<br />
|-<br />
| [[#EFI_firmware_updates|EFI firmware updates]] || {{G|Working}}<br />
|-<br />
| [[#Fingerprint_reader|Fingerprint reader]]{{Broken section link}} || {{R|Not working}}<br />
|}<br />
<br />
<br />
==UEFI==<br />
<br />
Before installing it is necessary to modify some UEFI Settings. They can be accessed by pressing the F2 key repeatedly when booting.<br />
* Change the SATA Mode from the default "RAID" to "AHCI". This will allow Linux to detect the NVME SSD. If dual booting with an existing Windows installation, Windows will not boot after the change but [https://triplescomputers.com/blog/uncategorized/solution-switch-windows-10-from-raidide-to-ahci-operation/ this can be fixed without a reinstallation].<br />
* Change Fastboot to "Thorough" in "POST Behaviour". This prevents intermittent boot failures.<br />
* Disable secure boot to allow Linux to boot.<br />
<br />
Installation of Arch Linux can proceed normally. Refer to the [[Installation guide]] for more information.<br />
<br />
<br />
== Power Management ==<br />
<br />
=== Suspend ===<br />
<br />
By default, the very inefficient s2idle suspend variant is incorrectly selected. This is probably due to the BIOS. The much more efficient deep variant should be selected instead:<br />
<br />
$ cat /sys/power/mem_sleep <br />
[s2idle] deep<br />
$ echo deep|sudo tee /sys/power/mem_sleep<br />
$ cat /sys/power/mem_sleep <br />
s2idle [deep]<br />
<br />
To make the change permanent add {{ic|1=mem_sleep_default=deep}} to your [[kernel parameters]].<br />
<br />
An easy way would be to add {{ic|1=mem_sleep_default=deep}} to the {{ic|1=GRUB_CMDLINE_LINUX_DEFAULT}} entry in /etc/default/grub:<br />
<br />
GRUB_CMDLINE_LINUX_DEFAULT="mem_sleep_default=deep"<br />
<br />
Read more regarding the sleep variants on the kernel documentation [https://www.kernel.org/doc/html/v4.18/admin-guide/pm/sleep-states.html].<br />
<br />
{{Warning|Some users have reported a problem where the CPUs get stuck in a high power state after resuming from S3 (deep) suspension [https://www.reddit.com/r/Dell/comments/91313h/xps_15_9570_c_state_bug_after_s3_sleep_and_modern/].}}<br />
<br />
=== Hibernate ===<br />
<br />
Works out of the Box see [[Power management/Suspend and hibernate]]<br />
<br />
=== Powertop ===<br />
<br />
{{ic|powertop}} is very efficient to manage power consumption.<br />
Run {{ic|powertop --auto-tune}}<br />
and compare the Watt consumption variation (battery must be unplugged). {{ic|powertop --auto-tune}} can be run at every boot.<br />
<br />
== Graphics ==<br />
<br />
=== kernel modules ===<br />
<br />
The nouveau module is known to cause kernel panics and freezes on Dell XPS 15 9570.<br />
<br />
One way to mitigate this would be by adding {{ic|nomodeset}} to the kernel options. However it's better to completely disable it with the blacklist method (recommended):<br />
<br />
{{hc|/etc/modprobe.d/blacklist.conf|<br />
blacklist nouveau<br />
blacklist rivafb<br />
blacklist nvidiafb<br />
blacklist rivatv<br />
blacklist nv}}<br />
<br />
=== [[NVIDIA Optimus]] ===<br />
<br />
The optimus configuration is a technology that allows an Intel integrated GPU and discrete NVIDIA GPU to be built into and accessed by a laptop. As the discret NVIDIA GPU card eats lots of power, we want to use the intergrated Intel card most of the time and activate/desactivate the NVIDIA GPU card only when required by a defined application. Due to a bug [https://bbs.archlinux.org/viewtopic.php?pid=1794626#p1794626], the XPS 15 9570's secondary NVIDIA GPU cannot be powered down by [[bbswitch]]. However, standard Linux power management is able to properly turn off the card when the driver is unloaded.<br />
<br />
==== Manually loading/unloading NVIDIA module ====<br />
<br />
One solution [https://bbs.archlinux.org/viewtopic.php?pid=1826641#p1826641] to the problem described above is to manually unload the nvidia module when not in use, which can be done as follows:<br />
<br />
[[Install]]<br />
* {{pkg|bumblebee}} - The main package providing the daemon and client programs.<br />
* {{pkg|nvidia}} - Official NVIDIA drivers for Linux.<br />
* {{pkg|powertop}} - Tool to verify power consumption.<br />
* {{aur|unigine-valley}} - Graphic intensive application for testing<br />
<br />
Make sure that {{pkg|bbswitch}} is uninstalled or at least disabled<br />
<br />
{{ic|bumblebee}} configuration, in the {{ic|[driver-nvidia]}} section<br />
{{hc|/etc/bumblebee/bumblebee.conf|<br />
# ''[driver-nvidia]'' section<br />
Driver<nowiki>=</nowiki>nvidia<br />
PMMethod<nowiki>=</nowiki>none}}<br />
<br />
Server X configuration for not auto adding gpu<br />
{{hc|/etc/X11/xorg.conf.d/01-noautogpu.conf|<br />
Section "ServerFlags"<br />
Option "AutoAddGPU" "off"<br />
EndSection}}<br />
<br />
{{ic|ipmi}} modules are loaded together with {{ic|nvidia}} and block its unloading. Create the two following files to disable them:<br />
{{hc|/etc/modprobe.d/disable-ipmi.conf|<br />
install ipmi_msghandler /usr/bin/false<br />
install ipmi_devintf /usr/bin/false}}<br />
{{hc|/etc/modprobe.d/disable-nvidia.conf|<br />
install nvidia /bin/false}}<br />
<br />
Now, add {{ic|nvidia}} and {{ic|ipmi}} in the modprobe.d blacklist to disable this functionality:<br />
<br />
{{hc|/etc/modprobe.d/blacklist.conf|<br />
blacklist nouveau<br />
blacklist rivafb<br />
blacklist nvidiafb<br />
blacklist rivatv<br />
blacklist nv<br />
blacklist nvidia<br />
blacklist nvidia-drm<br />
blacklist nvidia-modeset<br />
blacklist nvidia-uvm<br />
blacklist ipmi_msghandler<br />
blacklist ipmi_devintf}}<br />
<br />
Create 2 GPU management scripts for enabling and disabling discret NVIDIA graphical card [https://bbs.archlinux.org/viewtopic.php?pid=1826641#p1826641]:<br />
<br />
{{hc|enablegpu.sh|<br />
#!/bin/sh<br />
# allow to load nvidia module<br />
mv /etc/modprobe.d/disable-nvidia.conf /etc/modprobe.d/disable-nvidia.conf.disable<br />
<br />
# Remove NVIDIA card (currently in power/control <nowiki>=</nowiki> auto)<br />
echo -n 1 > /sys/bus/pci/devices/0000\:01\:00.0/remove<br />
sleep 1<br />
# change PCIe power control<br />
echo -n on > /sys/bus/pci/devices/0000\:00\:01.0/power/control<br />
sleep 1<br />
# rescan for NVIDIA card (defaults to power/control <nowiki>=</nowiki> on)<br />
echo -n 1 > /sys/bus/pci/rescan<br />
# someone said that modprobe nvidia is needed also to load nvidia, to check<br />
# modprobe nvidia}}<br />
<br />
{{hc|disablegpu.sh|<br />
#!/bin/sh<br />
<br />
modprobe -r nvidia_drm<br />
modprobe -r nvidia_uvm<br />
modprobe -r nvidia_modeset<br />
modprobe -r nvidia<br />
<br />
# Change NVIDIA card power control<br />
echo -n auto > /sys/bus/pci/devices/0000\:01\:00.0/power/control<br />
sleep 1<br />
# change PCIe power control<br />
echo -n auto > /sys/bus/pci/devices/0000\:00\:01.0/power/control<br />
sleep 1<br />
<br />
# Lock system form loading nvidia module<br />
mv /etc/modprobe.d/disable-nvidia.conf.disable /etc/modprobe.d/disable-nvidia.conf}}<br />
<br />
Create service locking NVIDIA GPU on shutdown<br />
A service which locks GPU on shutdown / restart when it is not disabled by {{ic|disablegpu.sh}} script is necessary. Otherwise, on next boot {{ic|nvidia}} will be loaded together with {{ic|ipmi}} modules (even if blacklisted with {{ic|install}} command) and it won't be possible to unload them then.<br />
<br />
{{hc|/etc/systemd/system/disable-nvidia-on-shutdown.service|<br />
[Unit]<br />
Description<nowiki>=</nowiki>Disables Nvidia GPU on OS shutdown<br />
<br />
[Service]<br />
Type<nowiki>=</nowiki>oneshot<br />
RemainAfterExit<nowiki>=</nowiki>true<br />
ExecStart<nowiki>=</nowiki>/bin/true<br />
ExecStop<nowiki>=</nowiki>/bin/bash -c "mv /etc/modprobe.d/disable-nvidia.conf.disable /etc/modprobe.d/disable-nvidia.conf <nowiki>||</nowiki> true"<br />
<br />
[Install]<br />
WantedBy<nowiki>=</nowiki>multi-user.target}}<br />
<br />
Reload systemd daemons and enable the {{ic|disable-nvidia-on-shutdown}} service:<br />
sudo systemctl daemon-reload<br />
sudo systemctl enable disable-nvidia-on-shutdown.service<br />
<br />
Allow gpu to poweroff on boot<br />
{{hc|/etc/tmpfiles.d/nvidia_pm.conf|<br />
w /sys/bus/pci/devices/0000:01:00.0/power/control - - - - auto}}<br />
<br />
Finally, check that everything is well configured:<br />
# Reboot and verify that nvidia is not loaded by running:<br />
#:{{bc|lsmod <nowiki>|</nowiki> grep nvidia}}<br />
#:Should not return anything<br />
# Disconnect / unplug charger and verify the power consumption with powertop is around 5W on idle (Dell XPS 15 4570, powertop --auto-tune previously launched, FHD screen with no touchscreen)<br />
# Enable GPU by using the enablegpu.sh script<br />
# Check that the GPU is loaded by using:<br />
#:{{bc|nvidia-smi}}<br />
# If good, launch unigine-valley with optirun:<br />
#:{{bc|optirun unigine-valley}}<br />
#:unigine-valley needs a GPU to work. Should activate the fans quickly.<br />
# Close all nvidia applications and disable gpu with the disablegpu.sh script<br />
# Check again power consumption, it should have gone back to a similar value as before<br />
<br />
==== Letting bumblebee automatically unload the kernel module ====<br />
<br />
Another possible way of shutting off the secondary GPU is to use a patched version of [[bumblebee]] that automatically unloads the nvidia kernel module when the card is not in use [https://bbs.archlinux.org/viewtopic.php?pid=1803779#p1803779]. This patch has already been merged into the {{ic|development}} branch of bumblebee [https://github.com/Bumblebee-Project/Bumblebee/pull/983] which can be obtained via {{aur|bumblebee-git}}. It is also provided by {{aur|bumblebee-forceunload}}, which is a modified version of {{pkg|bumblebee}} with this patch applied.<br />
<br />
[[Install]]<br />
* {{aur|bumblebee-git}} or {{aur|bumblebee-forceunload}} - [[Bumblebee]] with the {{ic|AlwaysUnloadKernelDriver}} option<br />
* {{pkg|nvidia}} - Official NVIDIA drivers for Linux.<br />
* {{pkg|mesa-demos}} - Mesa demos for testing device graphics capabilities<br />
<br />
Make sure that {{ic|AlwaysUnloadKernelDriver}} is set to {{ic|true}} in the {{ic|driver-nvidia}} section of your {{ic|bumblebee}} configuration:<br />
{{hc|/etc/bumblebee/bumblebee.conf|<br />
# ''[driver-nvidia]'' section<br />
KernelDriver<nowiki>=</nowiki>nvidia<br />
PMMethod<nowiki>=</nowiki>auto<br />
AlwaysUnloadKernelDriver<nowiki>=</nowiki>true}}<br />
<br />
While the above option unloads the nvidia kernel module when not in use, [[Xorg]] will still automatically discover the secondary graphics card and attempt to enable it. In order to prevent this, the option {{ic|AutoAddGPU}} should be disabled. However, this would lead to Xorg unable to detect the default integrated graphics card. The intel graphics card needs to be manually added to Xorg. This can be done by creating the following two configuration files in {{ic|/etc/X11/xorg.conf.d}}:<br />
{{hc|/etc/X11/xorg.conf.d/01-noautogpu.conf|<br />
Section "ServerFlags"<br />
Option "AutoAddGPU" "off"<br />
EndSection}}<br />
{{hc|/etc/X11/xorg.conf.d/20-intel.conf|<br />
Section "Device"<br />
Identifier "Intel Graphics"<br />
Driver "intel"<br />
# Uncomment line below if you are also having issues with backlight<br />
# Option "Backlight" "intel_backlight"<br />
EndSection}}<br />
<br />
Enable {{ic|bumblebeed.service}} to start on boot:<br />
sudo systemctl enable bumblebeed.service<br />
<br />
After restarting your system, you should be able to verify that everything is working properly:<br />
# Verify that nvidia is not loaded on boot by running:<br />
#:{{bc|lsmod <nowiki>|</nowiki> grep nvidia}}<br />
#:Should not return anything<br />
# Check that secondary graphics card is functioning properly with optirun:<br />
#:{{bc|optirun glxgears}}<br />
# Don't close this window just yet, we need to check that the nvidia module is loaded correctly:<br />
#:{{bc|lsmod <nowiki>|</nowiki> grep nvidia}}<br />
#:This time, it should be able to find nvidia in the loaded modules list<br />
# After closing {{ic|glxgears}}, check again to make sure that nvidia is properly unloaded:<br />
#:{{bc|lsmod <nowiki>|</nowiki> grep nvidia}}<br />
#:Should not return anything once again<br />
# At this point, the graphics card should be working correctly. You can further check the power consumption by disconnecting the charger and using [[Powertop]], there should be a significant power difference when {{ic|optirun glxgears}} is running and when it is not.<br />
<br />
=== Troubleshooting ===<br />
<br />
==== xbacklight ====<br />
<br />
To get xbacklight working and not conflicting with NVIDIA optimus:<br />
<br />
{{hc|/etc/X11/xorg.conf.d/20-intel.conf|<br />
Section "Device"<br />
Identifier "Intel Graphics"<br />
Driver "intel"<br />
Option "Backlight" "intel_backlight"<br />
EndSection<br />
}}<br />
<br />
==== NVRM: Failed to enable MSI; falling back to PCIe virtual-wire interrupts ====<br />
<br />
Sometimes it happens after suspend/resume. GPU could work fine without MSI. [http://us.download.nvidia.com/XFree86/Linux-x86/325.15/README/knownissues.html#msi_interrupts]. You could disable MSI by adding the following in '''/etc/modprobe.d/nvidia.conf''':<br />
<br />
options nvidia NVreg_EnableMSI=0<br />
<br />
==== Built-in screen flickers or does not come on with Linux kernel 5.0.0 - 5.0.7 ====<br />
<br />
Some users reported that running Linux kernel 5.0.0 to 5.0.7 can cause the screen to flicker (or stay completely black) when booting up or running an X server, making the built-in display unusable (see *[https://bugs.archlinux.org/task/61964])<br />
<br />
Currently, it seems that there are three possible workarounds :<br />
* [[Downgrade]] to Linux 4.20.13.<br />
* Apply [https://invent.kde.org/snippets/44 Albert Astals Cid's patch] on Linux kernel 5.0.x (see [[Kernel/Arch_Build_System|kernel Arch Build System]]).<br />
* Install {{Pkg|linux-lts}}<br />
* upgrade to Linux 5.0.8 or higher<br />
<br />
==== Lock-ups when resuming from suspend with nvidia module ====<br />
<br />
If your system locks up every time you resume from suspend with the following two lines in dmesg:<br />
<br />
[ 42.447364] pci 0000:01:00.0: Refused to change power state, currently in D3<br />
[ 46.896493] pci 0000:01:00.0: Refused to change power state, currently in D3<br />
<br />
you need to do the following:<br />
<br />
Into /etc/default/grub<br />
GRUB_CMDLINE_LINUX="nouveau.blacklist=0 acpi_osi=! acpi_osi=\"Windows 2015\" acpi_backlight=vendor mem_sleep_default=deep"<br />
<br />
This solved the lock-ups for me. (internal nvidia bug number: 2589324, [https://www.dell.com/community/XPS/XPS-15-9570-with-Ubuntu-18-04-1-not-resuming-after-suspend/m-p/7305094#M28897 dell resolution])<br />
<br />
== Wifi and Bluetooth ==<br />
<br />
These work well out of the box but you might need to update the firmware for better stability. For bluetooth, make sure you have everything installed as per the [[Bluetooth]] wiki page.<br />
<br />
$ lspci | grep Network<br />
3b:00.0 Network controller: Qualcomm Atheros QCA6174 802.11ac Wireless Network Adapter (rev 32)<br />
<br />
(please add a line here if you detect something different)<br />
<br />
=== Troubleshooting ===<br />
<br />
==== ath10k module crashes after suspend ====<br />
<br />
You may notice driver crashes after suspend/resume, which for the most part does not seem to impact the running system, with coredumps similar to:<br />
<br />
<nowiki><br />
kernel: WARNING: CPU: 6 PID: 27936 at drivers/net/wireless/ath/ath10k/mac.c:5746 ath10k_bss_info_changed+0xf96/0x1120 [ath10k_core]<br />
kernel: Modules linked in: uhid algif_hash cmac rfcomm fuse ccm ipt_MASQUERADE nf_conntrack_netlink nfnetlink xfrm_user xfrm_algo iptable_nat nf_nat_ipv4><br />
kernel: snd_hda_intel dcdbas x86_pkg_temp_thermal dell_smm_hwmon snd_hda_codec intel_powerclamp cfg80211 kvm_intel snd_hda_core input_leds snd_hwdep snd><br />
kernel: vfio_mdev mdev vfio_iommu_type1 vfio kvm irqbypass intel_gtt i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm agpga><br />
kernel: CPU: 6 PID: 27936 Comm: kworker/u24:42 Tainted: G U W OE 5.0.4-arch1-1-ARCH #1<br />
kernel: Hardware name: Dell Inc. XPS 15 9570/0HWTMH, BIOS 1.8.1 02/01/2019<br />
kernel: Workqueue: events_unbound async_run_entry_fn<br />
kernel: RIP: 0010:ath10k_bss_info_changed+0xf96/0x1120 [ath10k_core]<br />
kernel: Code: 24 8b 95 78 01 00 00 85 c0 0f 85 a7 00 00 00 89 d1 be 10 00 00 00 48 c7 c2 c0 b2 fa c0 4c 89 c7 e8 bf 68 00 00 e9 a5 f1 ff ff <0f> 0b 4c 89><br />
kernel: RSP: 0000:ffffb7a45422fcd0 EFLAGS: 00010282<br />
kernel: RAX: 00000000fffffffe RBX: ffff98f6d44815a0 RCX: 0000000000000000<br />
kernel: RDX: ffff98f6d4481938 RSI: ffffb7a45422fcf0 RDI: ffff98f6d81df418<br />
kernel: RBP: ffff98f6d81df418 R08: 0000000000000001 R09: 0000000000000000<br />
kernel: R10: 000000000000001f R11: 0000000000000000 R12: 0000000000000020<br />
kernel: R13: ffff98f6d81df420 R14: ffff98f6d4482598 R15: ffff98f6d44815a0<br />
kernel: FS: 0000000000000000(0000) GS:ffff98f6dc380000(0000) knlGS:0000000000000000<br />
179 94%<br />
kernel: process_one_work+0x1eb/0x410<br />
kernel: worker_thread+0x2d/0x3d0<br />
kernel: ? process_one_work+0x410/0x410<br />
kernel: kthread+0x112/0x130<br />
kernel: ? kthread_park+0x80/0x80<br />
kernel: ret_from_fork+0x35/0x40<br />
kernel: ---[ end trace 09ae3e174c178f98 ]---</nowiki><br />
<br />
Patched in some kernels and not others (which?), relevant links:<br />
<br />
* [https://bbs.archlinux.org/viewtopic.php?pid=1824143 BBS: Suspend issue with Dell XPS 9570] (related)<br />
* [https://bugzilla.kernel.org/show_bug.cgi?id=201499 buzbilla#201499: ath10k BUG on resume]<br />
* <br />
<br />
==== Bluetooth disappears (after suspend?) ====<br />
<br />
Possibly related to the previous instability issue, sometimes the adapter seems to completely disappear. As reported [https://www.dell.com/community/XPS/XPS-15-9570-Bluetooth-disappearing/td-p/6192457 here] (thanks [https://www.dell.com/community/user/viewprofilepage/user-id/3517956 w.v.w.], you can likely fix this by manually upgrading the firmware (to something newer than what's in {{Pkg|linux-firmware}}:<br />
<br />
1. Double check adapter (e.g. QCA6174, below)<br />
<br />
$ lspci | grep Network<br />
3b:00.0 Network controller: Qualcomm Atheros QCA6174 802.11ac Wireless Network Adapter (rev 32)<br />
<br />
2. Confirm hardware and current firmware version (e.g. hw3.2, firmware RM.4.4.1.c3-00013-QCARMSWPZ-1, below)<br />
<br />
$ journalctl -b | grep ath10k | egrep 'firmware|qca'<br />
kernel: ath10k_pci 0000:3b:00.0: qca6174 hw3.2 target 0x05030000 chip_id 0x00340aff sub 1a56:1535<br />
kernel: ath10k_pci 0000:3b:00.0: firmware ver RM.4.4.1.c3-00013-QCARMSWPZ-1 api 6 features wowlan,ignore-otp,no-4addr-pad,raw-mode,mfp crc32 fc0096a8<br />
<br />
3. Follow the instructions at https://wireless.wiki.kernel.org/en/users/Drivers/ath10k/firmware<br />
<br />
e.g. for the above adapter, download the latest firmware from https://github.com/kvalo/ath10k-firmware/tree/master/QCA6174/hw3.0 and<br />
<br />
$ cd /lib/firmware/ath10k/QCA6174/hw3.0<br />
$ sudo cp firmware-6.bin firmware-6.bin.bak<br />
$ sudo cp ~/Downloads/firmware-6.bin_RM.4.4.1.c3-00013-QCARMSWPZ-1 firmware-6.bin<br />
<br />
Either <code>sudo rmmod ath10k_core ath10k_pci && sudo modprobe ath10k_pci</code> (may not work, check dmesg) or reboot.<br />
<br />
<br />
== Touchpad and Touchscreen ==<br />
<br />
Wacom touchscreen and Synaptics touchpad:<br />
<br />
{{hc|$ xinput|2=<br />
⎡ Virtual core pointer id=2 [master pointer (3)]<br />
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]<br />
⎜ ↳ SYNA2393:00 06CB:7A13 Touchpad id=16 [slave pointer (2)]<br />
⎜ ↳ Wacom HID 488F Finger id=15 [slave pointer (2)]<br />
⎣ Virtual core keyboard id=3 [master keyboard (2)]<br />
[truncated]}}<br />
<br />
Both are i2c devices:<br />
<br />
{{hc|$ udevadm info /dev/input/mouse3 # touchscreen|2=<br />
P: /devices/pci0000:00/0000:00:15.0/i2c_designware.0/i2c-10/i2c-WCOM488F:00/0018:056A:488F.0006/input/input47/mouse3<br />
N: input/mouse3<br />
L: 0<br />
E: DEVPATH=/devices/pci0000:00/0000:00:15.0/i2c_designware.0/i2c-10/i2c-WCOM488F:00/0018:056A:488F.0006/input/input47/mouse3<br />
E: DEVNAME=/dev/input/mouse3<br />
E: MAJOR=13<br />
E: MINOR=35<br />
E: SUBSYSTEM=input<br />
E: USEC_INITIALIZED=5501073<br />
E: ID_INPUT=1<br />
E: ID_INPUT_TOUCHSCREEN=1<br />
E: ID_PATH=pci-0000:00:15.0-platform-i2c_designware.0<br />
E: ID_PATH_TAG=pci-0000_00_15_0-platform-i2c_designware_0}}<br />
<br />
{{hc|$ udevadm info /dev/input/mouse6 # touchpad|2=<br />
P: /devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-11/i2c-SYNA2393:00/0018:06CB:7A13.0007/input/input38/mouse6<br />
N: input/mouse6<br />
L: 0<br />
S: input/by-path/pci-0000:00:15.1-platform-i2c_designware.1-mouse<br />
E: DEVPATH=/devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-11/i2c-SYNA2393:00/0018:06CB:7A13.0007/input/input38/mouse6<br />
E: DEVNAME=/dev/input/mouse6<br />
E: MAJOR=13<br />
E: MINOR=38<br />
E: SUBSYSTEM=input<br />
E: USEC_INITIALIZED=4683741<br />
E: ID_INPUT=1<br />
E: ID_INPUT_TOUCHPAD=1<br />
E: ID_SERIAL=noserial<br />
E: ID_PATH=pci-0000:00:15.1-platform-i2c_designware.1<br />
E: ID_PATH_TAG=pci-0000_00_15_1-platform-i2c_designware_1<br />
E: DEVLINKS=/dev/input/by-path/pci-0000:00:15.1-platform-i2c_designware.1-mouse}}<br />
<br />
<br />
==Thunderbolt docks==<br />
<br />
===TB16===<br />
TB16 works fine if either Thunderbolt security is disabled in the BIOS or using {{Pkg|bolt}} to temporarily authorize or permanently enroll Thunderbolt devices with Thunderbolt security activated. Various quirks are detailed on the [[Dell TB16]] page.<br />
<br />
<br />
== EFI firmware updates ==<br />
<br />
They are 2 main ways to update efi firmware:<br />
* through running linux session with [[Fwupd]]<br />
* through UEFI<br />
<br />
=== [[Fwupd]] ===<br />
<br />
pacman -S fwupd<br />
Then, look at:<br />
sudo fwupdmgr get-updates<br />
sudo fwupdmgr refresh<br />
sudo fwupdmgr update<br />
<br />
=== UEFI ===<br />
<br />
Firmware images can be found at [https://www.dell.com/support/home/us/en/04/product-support/product/xps-15-9570-laptop/drivers Dell support page] as {{ic|XPS_15_9570_X.Y.Z.exe}} files.<br />
In order to install:<br />
* Download the desired firmware from section "Dell XPS 15 9570 System BIOS"<br />
* Save it in {{ic|/boot/EFI/Dell/Bios/}} (this path may vary, depending on your installation)<br />
* Reboot the system, and enter the boot menu by pressing repeatedly {{ic|F12}} on Dell logo<br />
* Choose "Bios Flash Update"<br />
* Select the file previously saved, and start the process<br />
The process will take about five minutes, during which the system will have some reboots and push fans at maximum speed. Finally the system will reboot normally.<br />
<br />
== Thermal management ==<br />
<br />
Thermal design is poor in the 9570, primarily due to higher-end chips being used inside the original system design without compensating for extra heat. This impacts numerous areas:<br />
<br />
# '''Performance''': at higher temperatures, CPU cores are throttled down to avoid damage. At best your system will not run as fast as it can, and at worst (and quite commonly), slower than cheaper chips and with sluggish performance.<br />
# '''Battery life''' is unnecessarily decreased.<br />
# '''System longevity''': running at constantly high temperatures will negatively impact equipment lifetime.<br />
# '''User discomfort''': uncomfortable heat and uncomfortable fan noise.<br />
<br />
Fortunately these can all be improved significantly to get your system running powerfully and quietly.<br />
<br />
=== Diagnosis ===<br />
<br />
You probably have a lot of dmesg output like this (for all CPUs), even with fairly light usage:<br />
<br />
kernel: CPU8: Package temperature above threshold, cpu clock throttled (total events = 8451)<br />
kernel: CPU8: Package temperature/speed normal<br />
<br />
Use [[lm_sensors]] and do some [[stress testing]] (with <code>stress</code> and <code>mprime</code>) to see what's happening with CPU core temperatures and fanspeed under different loads.<br />
<br />
=== Undervolting ===<br />
<br />
See [[Undervolting CPU]] on the wiki. Reduces heat and extends battery life.<br />
<br />
Possible configurations for <code>/etc/intel-undervolt.conf</code>:<br />
<br />
# i9-8950HK* (last updated 2019-03-30)<br />
<br />
undervolt 0 'CPU' -140<br />
undervolt 1 'GPU' -75<br />
<br />
* Tested extensively for moderate use. Was not stress tested for > 24 hours. Anecdotal reports of up to -200.<br />
<br />
This has a more minor impact than repasting but is significantly easier to do.<br />
<br />
=== Repasting & padding ===<br />
<br />
Significant improvements are possible by replacing the thermal grease used by Dell with better options available from Amazon, and adding some extra thermal padding. This might sound overwhelming but is well worth the effort, especially for newer CPUs. If you can't do this yourself consider finding a shop / technician who can do this for you. See the following article as the user comments below it for more info:<br />
<br />
* [https://www.ultrabookreview.com/14875-fix-throttling-xps-15/ UltraBookReview: How to Fix Throttling on the Dell XPS 15 9570 / 9560]<br />
* [https://photos.google.com/share/AF1QipMv5n4GppVgSUNEuU-Ie9VOHd0sAFAe5U57l7vsOKuAiPZpLeZn1tSBYpmrNzpFpw/photo/AF1QipPi-eGtEStq0uF4Shle0FE_OgbEDeeNtuF0KqLR?key=Y0pJUEtYTmp5SUhteGEtTGlZa0p3cVFVT2dyNmtB Picture of 9570 VRMs] - from comments of the above article<br />
<br />
=== Results ===<br />
<br />
According to the author of the UltraBookReview article above:<br />
<br />
<q>Undervolting seems to reduce temps at max load by 7-10C, while repasting seems to reduce temps by between 4-10C depending on your original paste job and paste used.</q><br />
<br />
From [https://bbs.archlinux.org/viewtopic.php?pid=1839474#p1839474 this forum post], much lower/softer fan speeds were needed to maintain the same temperatures, and temperature was a few degrees lower under similar loads. Fans were on less often and for less time when they were. Throttling was less prevalent and less severe.<br />
<br />
<br />
== Tips and Tricks ==<br />
<br />
===Systemd doesn't wait for Network===<br />
<br />
Few months ago systemd added "after= .. .. network.target" in /usr/lib/systemd/system/systemd-user-sessions.service<br />
<br />
This causes systemd to wait for network connection at boot, you can modify this file to remove network.target but it will be overwritten on systemd update. A better workaround is to add /etc/systemd/system/systemd-user-sessions.service with network.target removed.<br />
<br />
{{hc|/etc/systemd/system/systemd-user-sessions.service|2= <br />
# This file is part of systemd.<br />
#<br />
# systemd is free software; you can redistribute it and/or modify it<br />
# under the terms of the GNU Lesser General Public License as published by<br />
# the Free Software Foundation; either version 2.1 of the License, or<br />
# (at your option) any later version.<br />
<br />
[Unit]<br />
Description=Permit User Sessions<br />
Documentation=man:systemd-user-sessions.service(8)<br />
After=remote-fs.target nss-user-lookup.target<br />
<br />
[Service]<br />
Type=oneshot<br />
RemainAfterExit=yes<br />
ExecStart=/usr/lib/systemd/systemd-user-sessions start<br />
ExecStop=/usr/lib/systemd/systemd-user-sessions stop }}</div>Xythrezhttps://wiki.archlinux.org/index.php?title=Dell_XPS_15_(9570)&diff=576195Dell XPS 15 (9570)2019-06-23T06:50:18Z<p>Xythrez: Optimus: added explanation to issue with card and reformatted text to be more condensed</p>
<hr />
<div>[[Category:Dell]]<br />
[[ja:Dell XPS 15 (9570)]]<br />
{{Note|This page far from completed. Some not mentioned items could be same as [[XPS 15 9560]]. Most of it also applies to the Precision 5530}}<br />
<br />
{| class="wikitable" style="float: right;"<br />
| '''Device/Functionality''' || '''Status'''<br />
|-<br />
| [[#Suspend|Suspend]] || {{G|Working}}<br />
|-<br />
| [[#Hibernate|Hibernate]] || {{G|Working}}<br />
|-<br />
| [[#Graphics|Integrated Graphics]] || {{G|Working}}<br />
|-<br />
| [[#Graphics|Discrete Nvidia Graphics]] || {{Y|Modify}}<br />
|-<br />
| [[#Wifi_and_Bluetooth|Wifi]] || {{G|Working}}<br />
|-<br />
| [[#Wifi_and_Bluetooth|Bluetooth]] || {{G|Working}}<br />
|-<br />
| [[#Wifi_and_Bluetooth|rfkill]] || {{G|Working}}<br />
|-<br />
| Audio || {{G|Working}}<br />
|-<br />
| [[#Touchpad and Touchscreen|Touchpad]] || {{G|Working}}<br />
|-<br />
| [[#Touchpad and Touchscreen|Touchscreen]] || {{G|Working}}<br />
|-<br />
| Webcam || {{G|Working}}<br />
|-<br />
| Card Reader || {{G|Working}}<br />
|-<br />
| Function/Multimedia Keys || {{G|Working}}<br />
|-<br />
| [[#Power Management|Power Management]] || {{G|Working}}<br />
|-<br />
| [[#EFI_firmware_updates|EFI firmware updates]] || {{G|Working}}<br />
|-<br />
| [[#Fingerprint_reader|Fingerprint reader]]{{Broken section link}} || {{R|Not working}}<br />
|}<br />
<br />
<br />
==UEFI==<br />
<br />
Before installing it is necessary to modify some UEFI Settings. They can be accessed by pressing the F2 key repeatedly when booting.<br />
* Change the SATA Mode from the default "RAID" to "AHCI". This will allow Linux to detect the NVME SSD. If dual booting with an existing Windows installation, Windows will not boot after the change but [https://triplescomputers.com/blog/uncategorized/solution-switch-windows-10-from-raidide-to-ahci-operation/ this can be fixed without a reinstallation].<br />
* Change Fastboot to "Thorough" in "POST Behaviour". This prevents intermittent boot failures.<br />
* Disable secure boot to allow Linux to boot.<br />
<br />
Installation of Arch Linux can proceed normally. Refer to the [[Installation guide]] for more information.<br />
<br />
<br />
== Power Management ==<br />
<br />
=== Suspend ===<br />
<br />
By default, the very inefficient s2idle suspend variant is incorrectly selected. This is probably due to the BIOS. The much more efficient deep variant should be selected instead:<br />
<br />
$ cat /sys/power/mem_sleep <br />
[s2idle] deep<br />
$ echo deep|sudo tee /sys/power/mem_sleep<br />
$ cat /sys/power/mem_sleep <br />
s2idle [deep]<br />
<br />
To make the change permanent add {{ic|1=mem_sleep_default=deep}} to your [[kernel parameters]].<br />
<br />
An easy way would be to add {{ic|1=mem_sleep_default=deep}} to the {{ic|1=GRUB_CMDLINE_LINUX_DEFAULT}} entry in /etc/default/grub:<br />
<br />
GRUB_CMDLINE_LINUX_DEFAULT="mem_sleep_default=deep"<br />
<br />
Read more regarding the sleep variants on the kernel documentation [https://www.kernel.org/doc/html/v4.18/admin-guide/pm/sleep-states.html].<br />
<br />
{{Warning|Some users have reported a problem where the CPUs get stuck in a high power state after resuming from S3 (deep) suspension [https://www.reddit.com/r/Dell/comments/91313h/xps_15_9570_c_state_bug_after_s3_sleep_and_modern/].}}<br />
<br />
=== Hibernate ===<br />
<br />
Works out of the Box see [[Power management/Suspend and hibernate]]<br />
<br />
=== Powertop ===<br />
<br />
{{ic|powertop}} is very efficient to manage power consumption.<br />
Run {{ic|powertop --auto-tune}}<br />
and compare the Watt consumption variation (battery must be unplugged). {{ic|powertop --auto-tune}} can be run at every boot.<br />
<br />
== Graphics ==<br />
<br />
=== kernel modules ===<br />
<br />
The nouveau module is known to cause kernel panics and freezes on Dell XPS 15 9570.<br />
<br />
One way to mitigate this would be by adding {{ic|nomodeset}} to the kernel options. However it's better to completely disable it with the blacklist method (recommended):<br />
<br />
{{hc|/etc/modprobe.d/blacklist.conf|<br />
blacklist nouveau<br />
blacklist rivafb<br />
blacklist nvidiafb<br />
blacklist rivatv<br />
blacklist nv}}<br />
<br />
=== [[NVIDIA Optimus]] ===<br />
<br />
The optimus configuration is a technology that allows an Intel integrated GPU and discrete NVIDIA GPU to be built into and accessed by a laptop. As the discret NVIDIA GPU card eats lots of power, we want to use the intergrated Intel card most of the time and activate/desactivate the NVIDIA GPU card only when required by a defined application. Due to a bug [https://bbs.archlinux.org/viewtopic.php?pid=1794626#p1794626], the XPS 15 9570's secondary NVIDIA GPU cannot be powered down by [[bbswitch]]. However, standard Linux power management is able to properly turn off the card when the driver is unloaded.<br />
<br />
One solution [https://bbs.archlinux.org/viewtopic.php?pid=1826641#p1826641] to this problem is to manually unload the NVIDIA module when not in use, which can be done as follows:<br />
<br />
[[Install]]<br />
* {{pkg|nvidia}} - Official NVIDIA drivers for Linux.<br />
* {{pkg|bumblebee}} - The main package providing the daemon and client programs.<br />
* {{pkg|powertop}} - Tool to verify power consumption.<br />
* {{aur|unigine-valley}} - Graphic intensive application for testing<br />
<br />
Make sure that {{pkg|bbswitch}} is uninstalled or at least disabled<br />
<br />
{{ic|bumblebee}} configuration, in the {{ic|[driver-nvidia]}} section<br />
{{hc|/etc/bumblebee/bumblebee.conf|<br />
# ''[driver-nvidia]'' section<br />
Driver<nowiki>=</nowiki>nvidia<br />
PMMethod<nowiki>=</nowiki>none}}<br />
<br />
Server X configuration for not auto adding gpu<br />
{{hc|/etc/X11/xorg.conf.d/01-noautogpu.conf|<br />
Section "ServerFlags"<br />
Option "AutoAddGPU" "off"<br />
EndSection}}<br />
<br />
{{ic|ipmi}} modules are loaded together with {{ic|nvidia}} and block its unloading. Create the two following files to disable them:<br />
{{hc|/etc/modprobe.d/disable-ipmi.conf|<br />
install ipmi_msghandler /usr/bin/false<br />
install ipmi_devintf /usr/bin/false}}<br />
{{hc|/etc/modprobe.d/disable-nvidia.conf|<br />
install nvidia /bin/false}}<br />
<br />
Now, add {{ic|nvidia}} and {{ic|ipmi}} in the modprobe.d blacklist to disable this functionality:<br />
<br />
{{hc|/etc/modprobe.d/blacklist.conf|<br />
blacklist nouveau<br />
blacklist rivafb<br />
blacklist nvidiafb<br />
blacklist rivatv<br />
blacklist nv<br />
blacklist nvidia<br />
blacklist nvidia-drm<br />
blacklist nvidia-modeset<br />
blacklist nvidia-uvm<br />
blacklist ipmi_msghandler<br />
blacklist ipmi_devintf}}<br />
<br />
Create 2 GPU management scripts for enabling and disabling discret NVIDIA graphical card [https://bbs.archlinux.org/viewtopic.php?pid=1826641#p1826641]:<br />
<br />
{{hc|enablegpu.sh|<br />
#!/bin/sh<br />
# allow to load nvidia module<br />
mv /etc/modprobe.d/disable-nvidia.conf /etc/modprobe.d/disable-nvidia.conf.disable<br />
<br />
# Remove NVIDIA card (currently in power/control <nowiki>=</nowiki> auto)<br />
echo -n 1 > /sys/bus/pci/devices/0000\:01\:00.0/remove<br />
sleep 1<br />
# change PCIe power control<br />
echo -n on > /sys/bus/pci/devices/0000\:00\:01.0/power/control<br />
sleep 1<br />
# rescan for NVIDIA card (defaults to power/control <nowiki>=</nowiki> on)<br />
echo -n 1 > /sys/bus/pci/rescan<br />
# someone said that modprobe nvidia is needed also to load nvidia, to check<br />
# modprobe nvidia}}<br />
<br />
{{hc|disablegpu.sh|<br />
#!/bin/sh<br />
<br />
modprobe -r nvidia_drm<br />
modprobe -r nvidia_uvm<br />
modprobe -r nvidia_modeset<br />
modprobe -r nvidia<br />
<br />
# Change NVIDIA card power control<br />
echo -n auto > /sys/bus/pci/devices/0000\:01\:00.0/power/control<br />
sleep 1<br />
# change PCIe power control<br />
echo -n auto > /sys/bus/pci/devices/0000\:00\:01.0/power/control<br />
sleep 1<br />
<br />
# Lock system form loading nvidia module<br />
mv /etc/modprobe.d/disable-nvidia.conf.disable /etc/modprobe.d/disable-nvidia.conf}}<br />
<br />
Create service locking NVIDIA GPU on shutdown<br />
A service which locks GPU on shutdown / restart when it is not disabled by {{ic|disablegpu.sh}} script is necessary. Otherwise, on next boot {{ic|nvidia}} will be loaded together with {{ic|ipmi}} modules (even if blacklisted with {{ic|install}} command) and it won't be possible to unload them then.<br />
<br />
{{hc|/etc/systemd/system/disable-nvidia-on-shutdown.service|<br />
[Unit]<br />
Description<nowiki>=</nowiki>Disables Nvidia GPU on OS shutdown<br />
<br />
[Service]<br />
Type<nowiki>=</nowiki>oneshot<br />
RemainAfterExit<nowiki>=</nowiki>true<br />
ExecStart<nowiki>=</nowiki>/bin/true<br />
ExecStop<nowiki>=</nowiki>/bin/bash -c "mv /etc/modprobe.d/disable-nvidia.conf.disable /etc/modprobe.d/disable-nvidia.conf <nowiki>||</nowiki> true"<br />
<br />
[Install]<br />
WantedBy<nowiki>=</nowiki>multi-user.target}}<br />
<br />
Reload systemd daemons and enable the {{ic|disable-nvidia-on-shutdown}} service:<br />
sudo systemctl daemon-reload<br />
sudo systemctl enable disable-nvidia-on-shutdown.service<br />
<br />
Allow gpu to poweroff on boot<br />
{{hc|/etc/tmpfiles.d/nvidia_pm.conf|<br />
w /sys/bus/pci/devices/0000:01:00.0/power/control - - - - auto}}<br />
<br />
Finally, check that everything is well configured:<br />
# Reboot and verify that nvidia is not loaded by running:<br />
#:{{bc|lsmod <nowiki>|</nowiki> grep nvidia}}<br />
#:Should not return anything<br />
# Disconnect / unplug charger and verify the power consumption with powertop is around 5W on idle (Dell XPS 15 4570, powertop --auto-tune previously launched, FHD screen with no touchscreen)<br />
# Enable GPU by using the enablegpu.sh script<br />
# Check that the GPU is loaded by using:<br />
#:{{bc|nvidia-smi}}<br />
# If good, launch unigine-valley with optirun:<br />
#:{{bc|optirun unigine-valley}}<br />
#:unigine-valley needs a GPU to work. Should activate the fans quickly.<br />
# Close all nvidia applications and disable gpu with the disablegpu.sh script<br />
# Check again power consumption, it should have gone back to a similar value as before<br />
<br />
=== Troubleshooting ===<br />
<br />
==== xbacklight ====<br />
<br />
To get xbacklight working and not conflicting with NVIDIA optimus:<br />
<br />
{{hc|/etc/X11/xorg.conf.d/20-intel.conf|<br />
Section "Device"<br />
Identifier "Intel Graphics"<br />
Driver "intel"<br />
Option "Backlight" "intel_backlight"<br />
EndSection<br />
}}<br />
<br />
==== NVRM: Failed to enable MSI; falling back to PCIe virtual-wire interrupts ====<br />
<br />
Sometimes it happens after suspend/resume. GPU could work fine without MSI. [http://us.download.nvidia.com/XFree86/Linux-x86/325.15/README/knownissues.html#msi_interrupts]. You could disable MSI by adding the following in '''/etc/modprobe.d/nvidia.conf''':<br />
<br />
options nvidia NVreg_EnableMSI=0<br />
<br />
==== Built-in screen flickers or does not come on with Linux kernel 5.0.0 - 5.0.7 ====<br />
<br />
Some users reported that running Linux kernel 5.0.0 to 5.0.7 can cause the screen to flicker (or stay completely black) when booting up or running an X server, making the built-in display unusable (see *[https://bugs.archlinux.org/task/61964])<br />
<br />
Currently, it seems that there are three possible workarounds :<br />
* [[Downgrade]] to Linux 4.20.13.<br />
* Apply [https://invent.kde.org/snippets/44 Albert Astals Cid's patch] on Linux kernel 5.0.x (see [[Kernel/Arch_Build_System|kernel Arch Build System]]).<br />
* Install {{Pkg|linux-lts}}<br />
* upgrade to Linux 5.0.8 or higher<br />
<br />
==== Lock-ups when resuming from suspend with nvidia module ====<br />
<br />
If your system locks up every time you resume from suspend with the following two lines in dmesg:<br />
<br />
[ 42.447364] pci 0000:01:00.0: Refused to change power state, currently in D3<br />
[ 46.896493] pci 0000:01:00.0: Refused to change power state, currently in D3<br />
<br />
you need to do the following:<br />
<br />
Into /etc/default/grub<br />
GRUB_CMDLINE_LINUX="nouveau.blacklist=0 acpi_osi=! acpi_osi=\"Windows 2015\" acpi_backlight=vendor mem_sleep_default=deep"<br />
<br />
This solved the lock-ups for me. (internal nvidia bug number: 2589324, [https://www.dell.com/community/XPS/XPS-15-9570-with-Ubuntu-18-04-1-not-resuming-after-suspend/m-p/7305094#M28897 dell resolution])<br />
<br />
== Wifi and Bluetooth ==<br />
<br />
These work well out of the box but you might need to update the firmware for better stability. For bluetooth, make sure you have everything installed as per the [[Bluetooth]] wiki page.<br />
<br />
$ lspci | grep Network<br />
3b:00.0 Network controller: Qualcomm Atheros QCA6174 802.11ac Wireless Network Adapter (rev 32)<br />
<br />
(please add a line here if you detect something different)<br />
<br />
=== Troubleshooting ===<br />
<br />
==== ath10k module crashes after suspend ====<br />
<br />
You may notice driver crashes after suspend/resume, which for the most part does not seem to impact the running system, with coredumps similar to:<br />
<br />
<nowiki><br />
kernel: WARNING: CPU: 6 PID: 27936 at drivers/net/wireless/ath/ath10k/mac.c:5746 ath10k_bss_info_changed+0xf96/0x1120 [ath10k_core]<br />
kernel: Modules linked in: uhid algif_hash cmac rfcomm fuse ccm ipt_MASQUERADE nf_conntrack_netlink nfnetlink xfrm_user xfrm_algo iptable_nat nf_nat_ipv4><br />
kernel: snd_hda_intel dcdbas x86_pkg_temp_thermal dell_smm_hwmon snd_hda_codec intel_powerclamp cfg80211 kvm_intel snd_hda_core input_leds snd_hwdep snd><br />
kernel: vfio_mdev mdev vfio_iommu_type1 vfio kvm irqbypass intel_gtt i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm agpga><br />
kernel: CPU: 6 PID: 27936 Comm: kworker/u24:42 Tainted: G U W OE 5.0.4-arch1-1-ARCH #1<br />
kernel: Hardware name: Dell Inc. XPS 15 9570/0HWTMH, BIOS 1.8.1 02/01/2019<br />
kernel: Workqueue: events_unbound async_run_entry_fn<br />
kernel: RIP: 0010:ath10k_bss_info_changed+0xf96/0x1120 [ath10k_core]<br />
kernel: Code: 24 8b 95 78 01 00 00 85 c0 0f 85 a7 00 00 00 89 d1 be 10 00 00 00 48 c7 c2 c0 b2 fa c0 4c 89 c7 e8 bf 68 00 00 e9 a5 f1 ff ff <0f> 0b 4c 89><br />
kernel: RSP: 0000:ffffb7a45422fcd0 EFLAGS: 00010282<br />
kernel: RAX: 00000000fffffffe RBX: ffff98f6d44815a0 RCX: 0000000000000000<br />
kernel: RDX: ffff98f6d4481938 RSI: ffffb7a45422fcf0 RDI: ffff98f6d81df418<br />
kernel: RBP: ffff98f6d81df418 R08: 0000000000000001 R09: 0000000000000000<br />
kernel: R10: 000000000000001f R11: 0000000000000000 R12: 0000000000000020<br />
kernel: R13: ffff98f6d81df420 R14: ffff98f6d4482598 R15: ffff98f6d44815a0<br />
kernel: FS: 0000000000000000(0000) GS:ffff98f6dc380000(0000) knlGS:0000000000000000<br />
179 94%<br />
kernel: process_one_work+0x1eb/0x410<br />
kernel: worker_thread+0x2d/0x3d0<br />
kernel: ? process_one_work+0x410/0x410<br />
kernel: kthread+0x112/0x130<br />
kernel: ? kthread_park+0x80/0x80<br />
kernel: ret_from_fork+0x35/0x40<br />
kernel: ---[ end trace 09ae3e174c178f98 ]---</nowiki><br />
<br />
Patched in some kernels and not others (which?), relevant links:<br />
<br />
* [https://bbs.archlinux.org/viewtopic.php?pid=1824143 BBS: Suspend issue with Dell XPS 9570] (related)<br />
* [https://bugzilla.kernel.org/show_bug.cgi?id=201499 buzbilla#201499: ath10k BUG on resume]<br />
* <br />
<br />
==== Bluetooth disappears (after suspend?) ====<br />
<br />
Possibly related to the previous instability issue, sometimes the adapter seems to completely disappear. As reported [https://www.dell.com/community/XPS/XPS-15-9570-Bluetooth-disappearing/td-p/6192457 here] (thanks [https://www.dell.com/community/user/viewprofilepage/user-id/3517956 w.v.w.], you can likely fix this by manually upgrading the firmware (to something newer than what's in {{Pkg|linux-firmware}}:<br />
<br />
1. Double check adapter (e.g. QCA6174, below)<br />
<br />
$ lspci | grep Network<br />
3b:00.0 Network controller: Qualcomm Atheros QCA6174 802.11ac Wireless Network Adapter (rev 32)<br />
<br />
2. Confirm hardware and current firmware version (e.g. hw3.2, firmware RM.4.4.1.c3-00013-QCARMSWPZ-1, below)<br />
<br />
$ journalctl -b | grep ath10k | egrep 'firmware|qca'<br />
kernel: ath10k_pci 0000:3b:00.0: qca6174 hw3.2 target 0x05030000 chip_id 0x00340aff sub 1a56:1535<br />
kernel: ath10k_pci 0000:3b:00.0: firmware ver RM.4.4.1.c3-00013-QCARMSWPZ-1 api 6 features wowlan,ignore-otp,no-4addr-pad,raw-mode,mfp crc32 fc0096a8<br />
<br />
3. Follow the instructions at https://wireless.wiki.kernel.org/en/users/Drivers/ath10k/firmware<br />
<br />
e.g. for the above adapter, download the latest firmware from https://github.com/kvalo/ath10k-firmware/tree/master/QCA6174/hw3.0 and<br />
<br />
$ cd /lib/firmware/ath10k/QCA6174/hw3.0<br />
$ sudo cp firmware-6.bin firmware-6.bin.bak<br />
$ sudo cp ~/Downloads/firmware-6.bin_RM.4.4.1.c3-00013-QCARMSWPZ-1 firmware-6.bin<br />
<br />
Either <code>sudo rmmod ath10k_core ath10k_pci && sudo modprobe ath10k_pci</code> (may not work, check dmesg) or reboot.<br />
<br />
<br />
== Touchpad and Touchscreen ==<br />
<br />
Wacom touchscreen and Synaptics touchpad:<br />
<br />
{{hc|$ xinput|2=<br />
⎡ Virtual core pointer id=2 [master pointer (3)]<br />
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]<br />
⎜ ↳ SYNA2393:00 06CB:7A13 Touchpad id=16 [slave pointer (2)]<br />
⎜ ↳ Wacom HID 488F Finger id=15 [slave pointer (2)]<br />
⎣ Virtual core keyboard id=3 [master keyboard (2)]<br />
[truncated]}}<br />
<br />
Both are i2c devices:<br />
<br />
{{hc|$ udevadm info /dev/input/mouse3 # touchscreen|2=<br />
P: /devices/pci0000:00/0000:00:15.0/i2c_designware.0/i2c-10/i2c-WCOM488F:00/0018:056A:488F.0006/input/input47/mouse3<br />
N: input/mouse3<br />
L: 0<br />
E: DEVPATH=/devices/pci0000:00/0000:00:15.0/i2c_designware.0/i2c-10/i2c-WCOM488F:00/0018:056A:488F.0006/input/input47/mouse3<br />
E: DEVNAME=/dev/input/mouse3<br />
E: MAJOR=13<br />
E: MINOR=35<br />
E: SUBSYSTEM=input<br />
E: USEC_INITIALIZED=5501073<br />
E: ID_INPUT=1<br />
E: ID_INPUT_TOUCHSCREEN=1<br />
E: ID_PATH=pci-0000:00:15.0-platform-i2c_designware.0<br />
E: ID_PATH_TAG=pci-0000_00_15_0-platform-i2c_designware_0}}<br />
<br />
{{hc|$ udevadm info /dev/input/mouse6 # touchpad|2=<br />
P: /devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-11/i2c-SYNA2393:00/0018:06CB:7A13.0007/input/input38/mouse6<br />
N: input/mouse6<br />
L: 0<br />
S: input/by-path/pci-0000:00:15.1-platform-i2c_designware.1-mouse<br />
E: DEVPATH=/devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-11/i2c-SYNA2393:00/0018:06CB:7A13.0007/input/input38/mouse6<br />
E: DEVNAME=/dev/input/mouse6<br />
E: MAJOR=13<br />
E: MINOR=38<br />
E: SUBSYSTEM=input<br />
E: USEC_INITIALIZED=4683741<br />
E: ID_INPUT=1<br />
E: ID_INPUT_TOUCHPAD=1<br />
E: ID_SERIAL=noserial<br />
E: ID_PATH=pci-0000:00:15.1-platform-i2c_designware.1<br />
E: ID_PATH_TAG=pci-0000_00_15_1-platform-i2c_designware_1<br />
E: DEVLINKS=/dev/input/by-path/pci-0000:00:15.1-platform-i2c_designware.1-mouse}}<br />
<br />
<br />
==Thunderbolt docks==<br />
<br />
===TB16===<br />
TB16 works fine if either Thunderbolt security is disabled in the BIOS or using {{Pkg|bolt}} to temporarily authorize or permanently enroll Thunderbolt devices with Thunderbolt security activated. Various quirks are detailed on the [[Dell TB16]] page.<br />
<br />
<br />
== EFI firmware updates ==<br />
<br />
They are 2 main ways to update efi firmware:<br />
* through running linux session with [[Fwupd]]<br />
* through UEFI<br />
<br />
=== [[Fwupd]] ===<br />
<br />
pacman -S fwupd<br />
Then, look at:<br />
sudo fwupdmgr get-updates<br />
sudo fwupdmgr refresh<br />
sudo fwupdmgr update<br />
<br />
=== UEFI ===<br />
<br />
Firmware images can be found at [https://www.dell.com/support/home/us/en/04/product-support/product/xps-15-9570-laptop/drivers Dell support page] as {{ic|XPS_15_9570_X.Y.Z.exe}} files.<br />
In order to install:<br />
* Download the desired firmware from section "Dell XPS 15 9570 System BIOS"<br />
* Save it in {{ic|/boot/EFI/Dell/Bios/}} (this path may vary, depending on your installation)<br />
* Reboot the system, and enter the boot menu by pressing repeatedly {{ic|F12}} on Dell logo<br />
* Choose "Bios Flash Update"<br />
* Select the file previously saved, and start the process<br />
The process will take about five minutes, during which the system will have some reboots and push fans at maximum speed. Finally the system will reboot normally.<br />
<br />
== Thermal management ==<br />
<br />
Thermal design is poor in the 9570, primarily due to higher-end chips being used inside the original system design without compensating for extra heat. This impacts numerous areas:<br />
<br />
# '''Performance''': at higher temperatures, CPU cores are throttled down to avoid damage. At best your system will not run as fast as it can, and at worst (and quite commonly), slower than cheaper chips and with sluggish performance.<br />
# '''Battery life''' is unnecessarily decreased.<br />
# '''System longevity''': running at constantly high temperatures will negatively impact equipment lifetime.<br />
# '''User discomfort''': uncomfortable heat and uncomfortable fan noise.<br />
<br />
Fortunately these can all be improved significantly to get your system running powerfully and quietly.<br />
<br />
=== Diagnosis ===<br />
<br />
You probably have a lot of dmesg output like this (for all CPUs), even with fairly light usage:<br />
<br />
kernel: CPU8: Package temperature above threshold, cpu clock throttled (total events = 8451)<br />
kernel: CPU8: Package temperature/speed normal<br />
<br />
Use [[lm_sensors]] and do some [[stress testing]] (with <code>stress</code> and <code>mprime</code>) to see what's happening with CPU core temperatures and fanspeed under different loads.<br />
<br />
=== Undervolting ===<br />
<br />
See [[Undervolting CPU]] on the wiki. Reduces heat and extends battery life.<br />
<br />
Possible configurations for <code>/etc/intel-undervolt.conf</code>:<br />
<br />
# i9-8950HK* (last updated 2019-03-30)<br />
<br />
undervolt 0 'CPU' -140<br />
undervolt 1 'GPU' -75<br />
<br />
* Tested extensively for moderate use. Was not stress tested for > 24 hours. Anecdotal reports of up to -200.<br />
<br />
This has a more minor impact than repasting but is significantly easier to do.<br />
<br />
=== Repasting & padding ===<br />
<br />
Significant improvements are possible by replacing the thermal grease used by Dell with better options available from Amazon, and adding some extra thermal padding. This might sound overwhelming but is well worth the effort, especially for newer CPUs. If you can't do this yourself consider finding a shop / technician who can do this for you. See the following article as the user comments below it for more info:<br />
<br />
* [https://www.ultrabookreview.com/14875-fix-throttling-xps-15/ UltraBookReview: How to Fix Throttling on the Dell XPS 15 9570 / 9560]<br />
* [https://photos.google.com/share/AF1QipMv5n4GppVgSUNEuU-Ie9VOHd0sAFAe5U57l7vsOKuAiPZpLeZn1tSBYpmrNzpFpw/photo/AF1QipPi-eGtEStq0uF4Shle0FE_OgbEDeeNtuF0KqLR?key=Y0pJUEtYTmp5SUhteGEtTGlZa0p3cVFVT2dyNmtB Picture of 9570 VRMs] - from comments of the above article<br />
<br />
=== Results ===<br />
<br />
According to the author of the UltraBookReview article above:<br />
<br />
<q>Undervolting seems to reduce temps at max load by 7-10C, while repasting seems to reduce temps by between 4-10C depending on your original paste job and paste used.</q><br />
<br />
From [https://bbs.archlinux.org/viewtopic.php?pid=1839474#p1839474 this forum post], much lower/softer fan speeds were needed to maintain the same temperatures, and temperature was a few degrees lower under similar loads. Fans were on less often and for less time when they were. Throttling was less prevalent and less severe.<br />
<br />
<br />
== Tips and Tricks ==<br />
<br />
===Systemd doesn't wait for Network===<br />
<br />
Few months ago systemd added "after= .. .. network.target" in /usr/lib/systemd/system/systemd-user-sessions.service<br />
<br />
This causes systemd to wait for network connection at boot, you can modify this file to remove network.target but it will be overwritten on systemd update. A better workaround is to add /etc/systemd/system/systemd-user-sessions.service with network.target removed.<br />
<br />
{{hc|/etc/systemd/system/systemd-user-sessions.service|2= <br />
# This file is part of systemd.<br />
#<br />
# systemd is free software; you can redistribute it and/or modify it<br />
# under the terms of the GNU Lesser General Public License as published by<br />
# the Free Software Foundation; either version 2.1 of the License, or<br />
# (at your option) any later version.<br />
<br />
[Unit]<br />
Description=Permit User Sessions<br />
Documentation=man:systemd-user-sessions.service(8)<br />
After=remote-fs.target nss-user-lookup.target<br />
<br />
[Service]<br />
Type=oneshot<br />
RemainAfterExit=yes<br />
ExecStart=/usr/lib/systemd/systemd-user-sessions start<br />
ExecStop=/usr/lib/systemd/systemd-user-sessions stop }}</div>Xythrez