A while back I replaced my trustworthy Thinkpad T61 with a Dell Precision M4500. The only problem I had with the Thinkpad was with Nvidia not liking external monitors. (It would restart X when an external monitor was connected, and then the external would be the default monitor. Any attempt to e.g., clone both screens or even to change the default back to the LCD panel would just crash X again.) Since that’s pretty much a deal-breaker for a teacher, I decided to “upgrade” to a Dell Precision. I wanted something in the same “mobile workstation” class, with a good (non-chiclet) keyboard and touchpad. But the Precision has been much more trouble than the Thinkpad ever was (although external monitors do work with reasonable reliability). I’ve been gradually working through the issues as I have time.

# Nvidia Sometimes makes Compiz/X Hang or Crash

Sometimes, after logging in, either Compiz will fail to start (leaving me with un-managed windows) or will fail to render anything (giving a black screen) or X will hang completely. The former two cases can be “solved” by killing X (or, equivalently, restarting mdm), but the latter requires a magic-SysRq restart. After reading the usual round of irrelevant forum posts and old bug reports, I’ve tracked down a combination of changes that seem to mostly solve the issue.

Make sure Grub doesn’t switch to the graphical console (or tell the kernel to do the same):

GRUB_CMDLINE_LINUX="nouveau.modeset=0"
GRUB_TERMINAL=console


(Add to /etc/defaults/grub and then run update-grub.) Note that even with this change the kernel still switches to fbcon halfway through the boot process.

Blacklist the Nouveau kernel module: add a line blacklist nouveau to /etc/modprobe.d/blacklist.conf.

Remove the Nouveau X driver (make sure you have the official Nvidia drivers, obviously):

apt-get remove xserver-xorg-video-nouveau


Also note that if you have to restart X, it may leave a zombie Compiz running in the background, taking 100% CPU (which, on an 4-core machine, is not even noticeable). Running top and then doing kill -9 pid will fix that; just make sure you kill the right process.

A related issue seems to be that sometimes the Mate Panel is displayed on screen but not actually mapped, so you can’t click on it. Killing the panel fixes this, but it’s annoying.

The touchpad was so sensitive I could move the mouse cursor without touching the pad, just by hovering my finger over it. Also, the whole “disable the mouse while typing” thing doesn’t work, which, when combined with the above sensitivity, means that the mouse cursor likes to jump to random locations in my document while I’m typing.

evtest reports some crazy low pressure values: sometimes it will even report movement events with zero pressure. Although the Synaptics driver supports setting min/max thresholds for pressure that will register as clicks, I haven’t yet figured out if it supports just an overall “ignore all events below this pressure” threshold.

The following settings (in .xinitrc) is supposed to fix the sensitivity:

synclient FingerLow=83
synclient FingerHigh=88


But it just has the effect of making the touchpad less sensitive to intentional presses. Accidental touches seem to occur just as often. There doesn’t seem to be a single setting that will set a minimum threshold for pressure to register at all (i.e., as either move or press events).

Note that some people recommend changing the “FingerPress” setting, but that has been removed from newer versions of the driver.

For me, checking the box in the mouse settings that says “Disable while typing” has no effect. I had to add syndaemon -i 0.5s -d to my startup script manually to disable the touchpad while I’m typing.

# Dell’s UEFI Implementation is Beyond Broken

Going into the BIOS setup at all completely breaks the normal UEFI boot order. In order to boot back into Linux afterward I have to hit F12 to bring up the boot menu, and manually select the ubuntu EFI option. It doesn’t matter that ubuntu is set as the first, or only, boot entry; if I let the boot go through without my intervention it will hang at a black screen (pre-Grub). The “solution” involves using efibootmgr to change the boot order so that the ubuntu entry is not first in the list, but comes after some inactive entry; in my case, the first entry is that of legacy boot for the very same HD hosting Mint. (The “Modular Bay HD” has Windows 7; it’s replacing the DVDRW drive that would normally be in the expansion bay.) Note that this change cannot be made through BIOS; although the BIOS utility will show what are apparently the same settings, they won’t work. Here’s what the output of efibootmgr -v looks like (with my system currently booting direct into Linux):

BootCurrent: 0005
Timeout: 0 seconds
BootOrder: 0008,0005,0006
Boot0000  Diskette Drive    BIOS(1,0,00)
Boot0001  Internal HDD  BIOS(2,0,00)P0: Crucial_CT256MX100SSD1    .
Boot0002  USB Storage Device    BIOS(5,0,00)USB Storage Device.
Boot0003  CD/DVD/CD-RW Drive    BIOS(3,0,00)
Boot0004  Onboard NIC   BIOS(6,0,00)
Boot0005* ubuntu    HD(1,800,100000,4c57ed8c-a81a-4074-9270-85c4a244fd60)File(\EFI\ubuntu\shimx64.efi)
Boot0006* Modular Bay HDD   BIOS(2,0,00)SATA: ST9250410AS             .
Boot0008  Internal HDD  BIOS(2,0,00)SATA: Crucial_CT256MX100SSD1  .
Boot0009* USB Storage Device    BIOS(5,0,00)
BootFFFA* Internal Shell        Vendor(5990c250-676b-4ff7-8a0d-529319d0b254,)
BootFFFB* Diagnostic Boot       Vendor(5990c250-676b-4ff7-8a0d-529319d0b254,)

Note that you will have to manually restore this boot order if you do anything that might change or reset it, such as upgrading grub. Merely changing the grub config (update-grub) is fine, however.
(Note that you can’t use efibootmgr to modify the UEFI boot settings unless the system was booted in EFI mode. This means that if you started the system in legacy mode (e.g., to run a live CD) you cannot use it to fix your boot settings. But many newer live CD/USB distributions can also be booted in EFI mode; it’s just something to be aware of.)