Missing GPUGraphicsClockOffset and GPUMemoryTransferRateOffset in nvidia-settings for overclocking from the terminal (Linux)

For those that are using Linux and encountering the following error messages when trying to adjust the overclock offset in the terminal -

ERROR: Error assigning value 1000 to attribute 'GPUMemoryTransferRateOffset' (localhost:1[gpu:0]) as specified in assignment '[gpu:0]/GPUMemoryTransferRateOffset[3]=1000' (Unknown Error).

ERROR: Error assigning value -200 to attribute 'GPUGraphicsClockOffset' (localhost:1[gpu:0]) as specified in assignment '[gpu:0]/GPUGraphicsClockOffset[3]=-200' (Unknown Error).

Recent versions of nvidia-settings uses a different attribute -

GPUGraphicsClockOffsetAllPerformanceLevels

GPUMemoryTransferRateOffsetAllPerformanceLevels

So you need to run the commands in the following manner -

# nvidia-settings -a '[gpu:0]/GPUMemoryTransferRateOffsetAllPerformanceLevels=1000'

# nvidia-settings -a '[gpu:0]/GPUGraphicsClockOffsetAllPerformanceLevels=-200'

If you are running this headless then you may need to set your Xauthority file as below -

# DISPLAY=:1 XAUTHORITY=/run/user/1000/gdm/Xauthority nvidia-settings -c :1 -a '[gpu:0]/GPUGraphicsClockOffsetAllPerformanceLevels=-200'

You can find the xauth file for the session by using `ps ax` and greping for Xorg -

$ ps axf |grep Xorg

   8597 tty2     Sl+    0:02          \_ /usr/libexec/Xorg vt2 -displayfd 3 -auth /run/user/1000/gdm/Xauthority -nolisten tcp -background none -noreset -keeptty -novtswitch -verbose 3

VirGL 3D Acceleration on KVM with LibVirt and Nvidia Drivers

Nvidia drivers seem to be causing issues with the normal 3D acceleration libvirt configuration in virt-manager and Gnome Boxes. What happens is that the viewer returns a black/blank screen when the normal configuration to enable VirGL is applied -

<graphics type="spice">

  <listen type="none"/>

  <gl rendernode="/dev/dri/renderD128"/>

</graphics>

<video>

  <model type="virtio" heads="1" primary="yes">

    <acceleration accel3d="yes"/>

  </model>

  <address type="pci" domain="0x0000" bus="0x00" slot="0x01" function="0x0"/>

</video>

The error that it returns is -

qemu_spice_gl_scanout_texture: failed to get fd for texture

Looking around, this seems to be a problem due to EGL support being required for with the proprietary Nvidia drivers. The configuration that worked for me was this -

<graphics type="spice">

  <listen type="none"/>

</graphics>

<graphics type="egl-headless">

  <gl rendernode="/dev/dri/renderD128"/>

</graphics>

<video>

  <model type="virtio" heads="1" primary="yes">

    <acceleration accel3d="yes"/>

  </model>

  <address type="pci" domain="0x0000" bus="0x00" slot="0x01" function="0x0"/>

</video>

To check it is working inside the VM, use the following commands on the terminal in the VM -

$ dmesg |grep -i drm

[    5.326446] systemd[1]: Starting Load Kernel Module drm...

[    5.869884] [drm] pci: virtio-vga detected at 0000:00:01.0

[    5.871953] [drm] features: +virgl +edid

[    5.873360] [drm] number of scanouts: 1

[    5.873365] [drm] number of cap sets: 2

[    5.882054] [drm] cap set 0: id 1, max-version 1, max-size 308

[    5.882247] [drm] cap set 1: id 2, max-version 2, max-size 688

[    5.885640] [drm] Initialized virtio_gpu 0.1.0 0 for virtio0 on minor 0

[    5.891133] virtio_gpu virtio0: fb0: virtio_gpudrmfb frame buffer device

$ glxinfo |grep -i vir

    Device: virgl (0x1010)

OpenGL renderer string: virgl

Assembling a mdadm RAID volume with an external write-intent bitmap at boot on Fedora, CentOS and RHEL

When a drive drops out of an array, and then reintroduced, mdadm has to resync the array. This is long process, but can be sped up greatly by using a write-intent bitmap.

There are 2 types of bitmaps that can be created for an mdadm array - internal and external.

Internal bitmaps are written onto the disks in the array itself. It is the simplest and most straight-forward method and requires little setup and maintenance beyond initial creation. The drawback is that it affects write performance as the bitmap has to be continuously updated during writes.

Compared to internal bitmaps, external bitmaps have much less write performance penalty for mdadm RAID arrays. However, external bitmaps are difficult to set-up as they are files, which means that the RAID array has to be assembled after the partition containing the bitmap file has already been mounted. The reverse is normally the case - mdadm devices are usually assembled before partitions from /fstab are mounted.

After a lot of work reading documentation and testing out the behaviour of the system, here is a method that works (non-root RAID arrays only) on Fedora and derived distros such as RHEL and CentOS -

First add the bitmap to the array -

mdadm /dev/md15 --grow --bitmap=/boot/raid15.bitmap

If you place the bitmap outside of your rootfs (such as in /boot or another partition), add the line for that partition into the /etc/fstab.sys file for dracut to execute before RAID assembly. This step can be skipped if your external bitmap is on the rootfs.

echo "LABEL=boot /boot ext4 defaults 1 2" > /etc/fstab.sys

Scan the arrays for the mdadm.conf command to put into the conf file -

mdadm --detail --scan

Then, update the /etc/mdadm.conf file to assemble the array with the external bitmap -

ARRAY /dev/md15 UUID=<uuid> bitmap=/boot/raid15.bitmap

After this, we are ready to run dracut to regenerate the initramfs -

dracut -f

Finally, if SELinux is installed, mdadm won't be able to open the bitmap file properly. Use chcon to change the label on the file so that mdadm can open it -

chcon system_u:object_r:mdadm_var_run_t:s0 /boot/raid15.bitmap

That should be it. The md device should come back up on system boot. Check with -

cat /proc/mdstat

And make sure the array is assembled and that the bitmap is loaded.

Running Linux on ASUS N550JV - Fedora 19

The ASUS N550JV is the latest version of the performance/entertainment notebook N series from ASUS. It features a Haswell quad-core CPU with RAM expandable to 16GB and a replaceable HDD. The star of the show is the Full HD IPS screen, which is top-notch. Also, the entire case is made from aluminium and build quality is close to a MBP.

Linux runs rather well on the unit, but it took me some trial and error in order to get most of the features and components working properly on Fedora 19.

Update: The newest F19 kernel - 3.11.1-200 isn't supported by the bumblebee package and you will get poor battery life unless you manually echo "OFF" to /proc/acpi/bbswitch.

To install the previous version of the kernel from fedora-updates, download the RPMs from koji -
http://koji.fedoraproject.org/koji/buildinfo?buildID=463094

Model: ASUS N550JV CM067H
CPU: Intel i7-4700HQ Haswell Quad-Core (47w)
Discrete Graphics: Nvidia 750M 2GB DDR3
RAM: 1 x 8GB DDR3 1600mhz SODIMM (2 slots total, 1 slot free)
HDD: 1TB 5400rpm HDD (Replaceable)
Display: 15.6" IPS LCD Panel (LP156WF4-SPB1)


ACPI -

The main thing is to run a recent kernel and put acpi_osi="" in the kernel command line in grub. This will fix the backlight brightness and function keys. You may also have to manually load the asus-nb-wmi module in /etc/modules-load.d to ensure that the module load on boot.

Also, remember to take out any other ACPI kernel command line options you may have put in before, such as acpi_backlight as the keys will not work properly if you have those.

Also consider updating the BIOS to 206 as it has proven to be a stable configuration for me and the ACPI keys work consistently.


Optimus/Bumblebee -

To get Optimus/Bumblebee working, you will need to revert a ACPI commit in the kernel 3.8, see these links for more info -

https://bugzilla.kernel.org/show_bug.cgi?id=60561
https://github.com/Bumblebee-Project/bbswitch/issues/65
https://github.com/Bumblebee-Project/bbswitch/issues/446

The patch fixing this issue has been accepted in Linus' tree and appears to be on track for the 3.11 kernel release.

After installing the modified kernel RPM that reverts the change (not necessary when the 3.11 kernel comes out), and then installing the bumblebee RPMS from http://techies.ncsu.edu/wiki/bumblebee, everything works as expected.

Update: The ACPI handle works without patches as of kernel-3.10.10-200.fc19

Update 20131103: There is a problem with the Fedora Xorg which makes bbswitch unable shut off the Nvidia card after using optirun. This is detailed in the following issue ticket -

https://github.com/Bumblebee-Project/Bumblebee/issues/433

To fix this, I had to create  /etc/udev/rules.d/99-drm-bumblebee-fix-issue-433.rules (the file could be any name you want), with the following inside -

SUBSYSTEM=="drm", KERNEL=="card1", RUN+="/bin/rm /dev/dri/card1"


Subwoofer -

There is some information on how to get previous ASUS notebooks with an external subwoofer working under ALSA. However, I've not been able to get the subwoofer to work on the N550JV. If I do have some free time, might have a go at it. It's not a big issue for me, as it is a hassle to carry the subwoofer around, and on the desk I can connect the system to proper audio equipment that sounds much better than with the external subwoofer unit.


Full Disk Encryption -

The really interesting thing about this system is that it allows the user to set the ATA security passwords. When the system is equipped with a Full Disk Encryption supporting SSD or HDD, the FDE support can be completely seemless. You can set both master and user passwords in the UEFI BIOS. I've replaced the original HDD with a 960GB Crucial M500 SSD with ATA security enabled. No problems with this setup so far.


Power Management -

Put the following in /etc/pm/power.d/power (create the file with executable permissions if not present) -

#!/bin/sh

# Shell script to reduce energy consumption when running battery. Place
# it in /etc/pm/power.d/ and give execution rights.

#if on_ac_power; then
# Put specific AC power config here
#else
# Put specific Battery power config here
#fi

# Common Settings

# Enable Laptop-Mode disk writing
echo 5 > /proc/sys/vm/laptop_mode

# NMI watchdog should be turned off
for foo in /proc/sys/kernel/nmi_watchdog;
do echo 0 > $foo;
done

# Set SATA channel to power saving
for foo in /sys/class/scsi_host/host*/link_power_management_policy;
#do echo "min_power" > $foo;
#do echo "medium_power" > $foo;
#do echo "max_performance" > $foo;
done

# Activate USB autosuspend
# Autosuspend for USB device Bluetooth USB Host Controller [Atheros Communications]
echo 'auto' > '/sys/bus/usb/devices/3-5/power/control';
# Autosuspend for USB device Touchscreen [ELAN]
echo 'auto' > '/sys/bus/usb/devices/3-10/power/control';
# Autosuspend for USB device USB2.0-CRW [Generic]
echo 'auto' > '/sys/bus/usb/devices/3-8/power/control';

# Activate PCI autosuspend
for foo in /sys/bus/pci/devices/*/power/control;
do echo auto > $foo;
done

# Activate audio card power saving
echo '1' > '/sys/module/snd_hda_intel/parameters/power_save';

# VM Writeback timeout
echo '1500' > '/proc/sys/vm/dirty_writeback_centisecs';

# Turn off WOL
ethtool -s p3p1 wol d;

The script above will turn on most of the power management setting. However, regarding SATA link power management, some SSDs (and maybe some HDDs as well) do not work well with min_power, and I have corrupted disks with this setting on. Currently, I'm using medium_power and this setting is fine for my M500 SSD so far. However, please do your own tests before turning on the SATA link power management - I left this commented out in the script above for this reason!


SD Card Reader -

Update: It looks that that the kmod-staging driver for the rts5139 loads and detects the a block device, but does not actually detect media. So as of yet, the module isn't actually functional.

The card reader on the N550JV uses the RTS5139 chipset. As the driver for this is in staging, the module is not included in the default Fedora kernel. To fix this install kmod-staging from rpmfusion.org which should install the correct kmod-staging rpm for your current kernel. Be aware that this package sometimes lag behind the Fedora kernel.


Bluetooth -

My N550JV came with an Atheros AR9485 Card that includes also the bluetooth adapter (Atheros AR3012). Older versions of the kernel didn't include the USB ID of the device. See the following link for details -

https://bugzilla.kernel.org/show_bug.cgi?id=60726

I can confirm that this now work on Fedora since kernel 3.10.11.

You may also need to enable bt_coex. To do this, create a new file /etc/modprobe.d/ath9k.conf and put in the file the following -

options ath9k btcoex_enable=1

With the new kernel, bluetooth is now working fine on the system. However, as the Atheros card only support single-band wifi, it may be a good option to upgrade to an Intel card that supports dual-band.