Getting the Nvidia distribution drivers installed with Ubuntu 14.10 and possibly later

So do to the fact that my HTPC died, and I didn’t want to restore the OS from a backup, I opted instead to install a fresh (and reasonably modern) version of Kubuntu. Once installed I quickly ran into problems with the binary video driver installation. Yes, yes, I realize that I could simply instruct Kubuntu (or Ubuntu) to utilize the Canonical tracked binary drivers, however they’re always generally behind quiet a few versions, and for this system I like running the bleeding edge.

So my adventure in Nvidia driver installation begins yet again, a road I’ve been down many times…

Assuming you’ve downloaded the latest binary driver from Nvidia and try to install it you’ll immediately run into problems with the binary installer complaining that:

  • X windows is still running
  • The Nouveau module is loaded
  • The compiler can’t be found
  • 32bit libraries are missing (assuming you’re running 64bit OS like I am)

By far the most frustrating of these is Nouveau. Listen I’m all for open software, however the reality is that Nouveau is a poor substitute for the real deal from Nvidia. Would it be great if Nvidia open sourced their driver? Hell yes, however since they’re not willing to I’m stick using it in a binary format… Anyways, below are the steps I’ve used (recently) to achieve success in installing this driver:

  • Obtain the latest driver from Nvidia
  • Remove the packages xserver-xorg-video-nouveau and xserver-xorg-video-all
sudo dpkg -r xserver-xorg-video-nouveau xserver-xorg-video-all
  • Install the linux-headers package matching your kernel and the dkms package
sudo apt-get install linux-headers-`uname -r` dkms
  • Install GCC and make packages
sudo apt-get install gcc make
  • Install 32bit OpenGL libraries (if you’re running 64bit OS)
apt-get install libgl1-mesa-dri:i386 libgl1-mesa-glx:i386
  • Modify your GRUB configuration to set nomodeset on boot
  • edit: /etc/default/grub and find the line starting with: GRUB_CMDLINE_LINUX_DEFAULT. This usually this looks like:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
  • Add nomodeset to it:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash nomodeset"
  • Save the file and run update-grub
sudo update-grub
  • Reboot

Once rebooted make sure that X windows is shutdown. Usually if X is running on boot in Kubuntu or Ubuntu environments, it’s due to kdm, gdm, or lightdm

sudo stop lightdm

After that, try and run the nvidia binary driver installer and allow it to install the drivers. Hopefully all will go smoothly and your system will be ready to go. Once complete you can simply restart X windows:

sudo start lightdm

Good luck, and if you have problems feel free to let me know in the comments section!

My HTPC finally died…

So over the last few years I’ve been a very simple HTPC setup. It consisted of an Intel E4500, 4GB ram system with a GTX 780 Nvidia card running Kubuntu Linux 12.04.

For storage I booted off a simple USB stick, after 3 years I’ve killed 5 USB sticks with constant writes, caching, swapping etc. Clearly not an ideal environment for a USB stick to operate in but hey, who cares they’re cheap and easy to backup / restore.

That said, this last time around I decided that it was time to upgrade, and I happen to have some spare parts laying around, including a spare case, so that’s exactly what I did.

New system is still running Kubuntu, however upgraded to 14.10, I salvaged the video card and the 4GB of ram, and added another 4GB of ram with new motherboard and E8500 CPU. Additionally the new case and better (and quieter) cooling as well as more room, and of course, the major bonus, I tossed an SSD in for the system disk.

I’ve thought about running Kodi on this system for a while but haven’t had much time to configure it, I did leave myself plenty of room on the SSD for additional operating system partitions in the future.

My little cluster…

So recently I’ve put together a test cluster for testing Lustre (www.lustre.org), which is a file system technology that I work directly on in my day job.  The cluster is a bit interesting as it’s a 5 node, dual E5540, DDR IB system.

In general it works well, however it really burns power so lately it’s not been on all the time.

IMG_20150402_113845 IMG_20150402_113827

Dell XPS 13 (9333) A06 BIOS (UPDATED)

 

Dell has released A06 BIOS version for the XPS 13 (9333) model. The release notes (available here) are extremely light on detail, however I can tell you it does seem to resolve (at least so far for me, and others) the issue with unreliable suspend and resume!

It doesn’t seem to resolve the bizarre problem with delayed brightness key controls though.

For those of you tux lovers out there, the upgrade is simple, grab a good USB stick (the cheap ones tend to not boot correctly), install FreeDOS via unetbootin, download the BIOS image .exe file, copy it to your USB stick, boot the USB stick, and the execute the .exe, the BIOS installer will start, walk through the prompts and wait for it to reboot your system.

UPDATE:

Well, sadly after a few days of testing, it would seem the bug still persists within the BIOS which results in lock up on shutdown. It took considerably longer to get there, however it’s still present.

Dell XPS 13 (9333) with A05 BIOS

So over the last few weeks I’ve been trying to sort out the final problems with my XPS 13. The last, and most annoying problem I’ve seen is the frequent and seemingly random lockups on suspend.

This bothers me a lot because it effectively means I can’t just close the lid on the laptop and toss it in a bag and go.

Based on what I’ve observed the issue seems to be solidly within the A05 BIOS. From my understanding, speaking with Dell Pro Support, this BIOS revision is beta, and only available to those users who have either received new systems after October 15th 2014, or had their motherboards replaced to address the coil whine problem.

The issue it self appears to relate closely to the power state the laptop is in, and the fact that the OS may change the power state when plugged in, to something not regonized or supported by the BIOS at the time.

So effectively you can suspend and resume reliably, so long as you don’t have the power plug, plugged in while the system is running. Of that, it seems to take some time (i.e. secondary power state change) for it to reliably trigger the hang when suspending into memory.

I can’t seem to determine much past that as the OS has handed off duties to the BIOS and it’s the BIOS which fails to bring the system down to sleep.

If you want to comment with Dell on this, I have an active thread here:

http://en.community.dell.com/techcenter/os-applications/f/4613/t/19604474

Another year, another Super computing, this year, New Orleans

Well, another year has gone by and another Super computing conference. This years SC14 conference was held in New Orleans. The notable things I found this year, at least things I found interesting where the 8TB archival drive from Seagate, all of the various 3M NOVEC cooling demonstrations, the D-WAVE quantum processor and other items. I grabbed pictures and they’re available below, enjoy!

Continue reading

Electical noise from Dell XPS13 with upgrade motherboard and BIOS

So many of us that have purchased the Dell XPS 13 (9333) with Haswell core i7 processors have noticed a rather annoying and near constant electrical noise. If you have an earlier generation of this laptop (early 2014 model year) you’ve probably heard this noise. If you’ve looked into this at all, you’ve probably found that Dell has a replacement board to fix this problem.

Unfortunately even after replacing the motherboard, upgrading the BIOS, etc. you’ll still have this noise. That said, there seems to be a simple solution, until an official second fix from Dell is released. This solution is to remove the back cover (Torx T5 required) and unplug the right side speaker from the motherboard.

I believe the noise that people are hearing with the upgraded motherboards is related to poor electrical shielding around that speaker assembly.  Once unplugged the noise will be almost completely gone, (There is still some noise, but nowhere near as loud as before).

I’m thinking that I might try to use RF shielding tape around the entire speaker assembly, as well as below the WIFI card. Sadly, I don’t have a nice scope, so I can’t really go probing around to see where the noise is being introduced.

My Dell XPS 13 `sputnik’ Linux configuration

So, back in September I decided to purchase a new laptop, the one I decided on was the Dell XPS 13 Sputnik (9333). This is an Intel Core i7, 8GB RAM, 256GB mSATA based laptop which ships with Ubuntu 12.04 LTS.

Dell_XPS_13_Sputnik_3_Large

My first thoughts on this laptop are positive, in general the build quality is high, screen looks great, as fast (very fast for such a thin ultrabook). That said the unit initially shipped to me suffered from the dreaded coil whine issue discussed on this thread, as well as a few other issues which, with the help of others I’ve been able to solve pretty quickly.

There’s a great blog which details most of the things which you need to take care of to get this system working well. That said there’s a few more things that you’ll need to do. If you’re like me, you’ve probably blown away the stock OS, and installed something more recent.

First thing I did was modify the als.sh script on the xps13 blog:

--- als.sh      2014-10-15 22:20:26.592234453 -0600
+++ /usr/local/bin/als.sh       2014-10-11 23:37:33.150956572 -0600
@@ -85,15 +85,17 @@
 fi
 
 # Check idle time
-. /usr/share/acpi-support/power-funcs
-getXuser
-currIdleTime=`su $XUSER -c "dbus-send --session --dest=org.freedesktop.ScreenSaver \
-                            --type=method_call --print-reply --reply-timeout=1000 \
-                            /ScreenSaver org.freedesktop.ScreenSaver.GetSessionIdleTime \
-                            | grep uint32 | sed 's:.*uint32 \+\([0-9]\+\).*:\1:g'"`
-if [ $currIdleTime -gt $idleTimeout ]; then
-    echo "Timeout expired, ignoring ambient light changes"
-    exit 0
+if [ -f /usr/share/acpi-support/power-funcs ]; then
+       . /usr/share/acpi-support/power-funcs
+       getXuser
+       currIdleTime=`su $XUSER -c "dbus-send --session --dest=org.freedesktop.ScreenSaver \
+                                   --type=method_call --print-reply --reply-timeout=1000 \
+                                   /ScreenSaver org.freedesktop.ScreenSaver.GetSessionIdleTime \
+                                   | grep uint32 | sed 's:.*uint32 \+\([0-9]\+\).*:\1:g'"`
+       if [ $currIdleTime -gt $idleTimeout ]; then
+           echo "Timeout expired, ignoring ambient light changes"
+           exit 0
+       fi
 fi
 
 # Use xbacklight if the given path is wrong
@@ -115,6 +117,7 @@
         fi
         for i in `seq $curr $incr $target`; do
             echo $i > $backlightPath
+            echo $i > /tmp/als_state
             sleep $timeout
         done
     else
@@ -129,4 +132,4 @@
         break
     fi
     j=$(($j+1))
-done
\ No newline at end of file
+done

Effectively the patch above simply checks to see if power-funcs  actually exists.

Next I upgraded to 3.17 kernel. This solved problems with white noise, as well as wireless stability issues.

After that you’ll want to disable power features on the mSATA SSD by creating /etc/pm/config.d/hook_blacklist.conf and adding the following line:

HOOK_BLACKLIST="95hdparm-apm sata_alpm"

 

After some discovery, I found that not all power control features are here. A large number of them are stored in /etc/power.d/10-power_script. you’ll want to patch this file to omit the features which will adversely affect the SSD

--- power.d/10-power_script     2014-10-18 15:34:15.820269065 -0600
+++ power.d/10-power_script     2014-10-18 15:33:08.976265876 -0600
@@ -41,16 +41,16 @@
 #echo $GOVERNOR > /sys/devices/system/cpu/cpu3/cpufreq/scaling_governor
 
 # Enable SATA link power Managmenet for host0
-echo $SATA > /sys/class/scsi_host/host0/link_power_management_policy
+#echo $SATA > /sys/class/scsi_host/host0/link_power_management_policy
 
 # Enable SATA link power Managmenet for host1
-echo $SATA > /sys/class/scsi_host/host1/link_power_management_policy
+#echo $SATA > /sys/class/scsi_host/host1/link_power_management_policy
 
 # Enable SATA link power Managmenet for host2 - it used to slow down keyboard typing
-echo $SATA > /sys/class/scsi_host/host2/link_power_management_policy
+#echo $SATA > /sys/class/scsi_host/host2/link_power_management_policy
 
 # Enable SATA link power Managmenet for host3
-echo $SATA > /sys/class/scsi_host/host3/link_power_management_policy
+#echo $SATA > /sys/class/scsi_host/host3/link_power_management_policy
 
 # Autosuspend for USB device Synaptics Large Touch Screen [SYNAPTICS]
 findPath 06cb 0af8
@@ -79,7 +79,7 @@
 echo $CONTROL > /sys/bus/pci/devices/0000:00:1f.3/power/control
 
 # Runtime PM for PCI Device Intel Corporation Lynx Point-LP SATA Controller 1 [AHCI mode]
-echo $CONTROL > /sys/bus/pci/devices/0000:00:1f.2/power/control
+#echo $CONTROL > /sys/bus/pci/devices/0000:00:1f.2/power/control
 
 # Runtime PM for PCI Device Intel Corporation Haswell-ULT Integrated Graphics Controller
 echo $CONTROL > /sys/bus/pci/devices/0000:00:02.0/power/control

Lastly, I had to upgrade xserver-xorg-video-intel to at least version 2.99.916 to ensure that resume would function correctly.