Among my many computers I have a Dell Studio 1749, a rather powerful machine with four processors. It's my favorite laptop and the one I prefer to use. I have the current Fedora release installed on it, and I regularly update the operating system as new releases appear. But over the years, the list of things wrong with it has gradually increased. Before the repairs I explain below, this was the list of problems:

• There was no sound from the headphone jacks.
• The SD Card reader had stopped working.
• The display backlight wouldn't turn off.
• I couldn't update the BIOS from Linux.
• The suspend to RAM/disk feature recently stopped working.

Most of these problems are what are called "regressions" in Linux kernel development — things that have gotten worse over time. Some of the repairs listed below should work on other Dell machines, and machines from other manufacturers that have similar hardware. The outcome isn't a total victory, and the repairs range from conclusive to embarrassing hacks. Some are only partial fixes.

All the repairs below result at least in part from Web research, and many people deserve credit for some of the details. With that, here we go.

This problem was caused by the Intel audio adaptor not knowing what kind of computer it was connected to, and what features the machine had. The symptom was normal sound until headphones were plugged into one of the two headphone jacks, after which sound would stop working. Here's the remedy:

• Create a file with any convenient name (I used "snd-hda-intel.conf") containing this:

  options snd-hda-intel model=dell-m6-dmic

• Place this file in the directory /etc/modprobe.d/
• Reboot.

This is one of the definitive fixes.

• Create a file with any convenient name (I chose "cardreader-firewire.conf") containing this:

  options firewire-ohci quirks=0x10

• Place this file in /etc/modprobe.d/
• Because this driver is loaded early in the boot process, we need to recreate the initramfs file that's located in the system /boot directory. Here's how we do that in Fedora (as root):

  # dracut --force

• Reboot.

This is one of the more hacky fixes — it essentially gets around a problem whose cause is unknown. The fix involves two Bash scripts, one to activate/deactivate a daemon and place a hook in ~./bashrc for future logins, and a daemon script that monitors screen brightness. The idea is if the brightness level declines below a certain minimum, the daemon shuts down the display entirely. This allows the user to set existing screen-saver controls to dim the display after a certain idle time, which triggers the daemon's display shutdown response. Normally the screensaver software can do this on its own, but, for reasons unknown, not on this Dell laptop.

This is an important fix, even though it's somewhat of a hack (even though it doesn't locate and fix the true cause). One reason is the backlight on a laptop is a fragile light source with a limited life. It's best to turn it off when it's not in use. Another reason is that a modern GPU requires a lot of power, and if it's not in use it really should be turned off to extend battery life.

• This setup script first installs a required utility named vbetool if it's not already present. Then it tests to see if the daemon is already active, and asks the user what to do. To enable the daemon it edits ~.bashrc to automatically start the daemon on the next login, then starts the daemon. To disable the daemon it removes its own edit to ~.bashrc and kills the daemon.
• This is the daemon script — it should be placed anywhere convenient, but in the same directory as the setup script. This script (updated in August 2012) uses the dbus system to examine the state of the display dimming control (that's System Settings ... Power Management ... Energy Saving Settings ... Dim Display) and shuts off the backlight if display dimming is active. I expected this bug to be fixed eventually, but as of Fedora 17, no such luck.

For both these scripts:

• Click the above links and download them from your browser.
• Chage their names from (name).txt to (name).sh
• Make them executable:

  $ chmod +x *.sh

• Place them in any convenient directory (both in the same directory).
• Edit install_uninstall.sh — type in the path where it's located.
• Run the install/uninstall script:

  $ ./install_uninstall.sh

This episode is so infuriating that I am somewhat at a loss for words. As I mentioned above, I have Fedora installed on this computer, and it's not dual-boot. You know — a self-respecting laptop running Linux. Should be no big deal.

I recently realized my BIOS was falling behind the Dell revisions, so I decided to re-flash it. Replacing a computer's BIOS is a nontrivial undertaking and it must be done carefully. In the worst case, by not being careful you can turn a computer into a paperweight.

I considered my options. The most obvious approach is to get the default upgrade executable from Dell, which inevitably is a Windows executable, and run it in some kind of temporary Windows environment like wine or a virtual machine like VirtualBox running some version of Windows. But this option has been taken away recently — Dell now only offers 64-bit Windows BIOS upgrade executables, and most temporary Windows or DOS environments cannot run it.

But there's another option — because Dell now sells some of their machines with Linux on board, they also offer some Linux maintenance tools. So in some cases, one can get a binary BIOS image and install it using a Linux installer. Here's how this option works:

• Install some Dell utilities (as root):

  # yum -y install yum-dellsysid firmware-addon-dell

• Query your system to get its system ID:

  # getSystemId

• Example output:

  Libsmbios version: 2.2.28
  Product Name: Studio 1749
  Vendor: Dell Inc.
  BIOS Version: A05
  System ID: 0x041B
  Service Tag: SSSTTT
  Express Service Code: 999999999
  Asset Tag:
  Property Ownership Tag:

• For the next step, you only need the System ID, in this case "0x041B" (for a Dell 1749 laptop).
• Go to this Dell BIOS headers archive and locate the binary archive containing the current BIOS for your system. The desired archive:
  • Has the System ID number acquired above, located after "_dev_" and before "_version_"
  • Has the highest (most recent) version number.
• Imagine my shock, after spending a huge amount of time resarching this option, at discovering that the Dell 1749 system ID (0x041B) is not in the list of Dell BIOS headers.
• After this discovery I gave up on this option, which is more fully described (for Debian) here.

But thinking my outdated BIOS might be the cause of some of the system problems I listed above, I was determined to upgrade my BIOS. So ... what did I do? You may not believe this, but I:

• Located a spare laptop drive.
• Swapped out my Linux system drive and installed the spare drive.
• Installed Windows 7 (which I knew would permit execution of a 64-bit Windows executable) on the spare drive.
• Acquired the only BIOS upgrade option Dell provides for this machine, located here.
• Ran the BIOS upgrade executable and flashed the new BIOS.
• Swapped out the Windows drive and tossed it into a corner.

I can imagine some clueless Dell product manager reading this account and saying, "But doesn't everyone want to run the latest version of Windows? What else is there?"

This is a partial solution. It's not complete and has some unresolved issues — it's only a first step.

• Create a file with any convenient name (I called mine "blacklist-suspend.conf") and this content:

  blacklist firewire_core
  blacklist firewire_ohci

• Put this file in /etc/modprobe.d/
• Because these drivers are loaded early in the boot proces, we need to recreate initramfs again:

  # dracut --force

• The good news is this allows suspend to RAM/Disk again. The bad news is you can't use Firewire — but Firewire is as dead as Hula Hoops and Pez dispensers, so who cares?

But these's more bad news — although this change allows suspend to RAM and disk to proceed, and recovery from suspend seems normal, there's a problem — any subsequent screensaver event locks up the display and there's no obvious recovery method. I'm still working on this issue.

From time to time on this machine — actually, all my machines — the CPU load goes up to 100% and stays there. Unlike the other bugs discussed on this page, this bug isn't limited to the Dell laptop. By running htop I can see that the culprit is the X server.

My remedy is to start a virtual terminal, change to runlevel 3, and return to runlevel 5 again. I have no idea why this works, and I certainly have no remedy. Web searches don't turn up anything on this bug. And it affects systems regardless of which video processor is present — ATI, Nvidia, Intel. They all do it. I have no idea about the cause of this bug, and no remedy.

Having worked through the various difficulties above, and to avoid an obvious reader objection, I tried installing Ubuntu (Kubuntu, actually, version 11.04) on the Dell problem laptop instead of Fedora. To my surprise, I saw all the same problems with all the same elements. The backlight wouldn't turn off, the system couldn't read the SD card, suspend to RAM/disk still failed, and so forth. No difference. This means the problems are in the kernel, the X server and various drivers, not anything having to do with a particular distribution.

All these issues represent regressions (steps backwards) in Linux kernel/driver development. I guess it's too much trouble to test kernel and driver changes using actual computers.

It's well-known that many Linux kernel maintainers have priorities other than the behavior of desktop and laptop machines. As just one example, Linus Torvalds supposedly has a reputation as a "heavy iron" (dedicated server) man. And there's no doubt that dealing with end users and their eternally quirky end user machines must be very frustrating compared to making a kernel change that will very likely work optimally on 10,000 identical blade processors in a massive server rack.

Further, no one should doubt that suspend-to-RAM/Disk is a complex, delicate process, one in which every active driver must behave itself in complex, subtle ways, across many different hardware architectures. Add to this the fact that many desktop and laptop machines were designed to only run Windows and aren't necessarily even tested with other operating systems.

The bottom line is that each of the problems addressed in this article should be fixed by formal kernel and driver changes, rather than by end-user hacks like these. After some years of gradual improvements in how Linux performs on end-user machines, it's discouraging to see a sudden wave of regressions and what appears to be indifference to testing of changes on end-user machines.