The mystery of the dead speaker
Congratulations on getting the new 2.6 version of the kernel installed on your computer. Did you check your speakers? do they still work? probably not. Don't worry they can be brought back to life easily.
When you search around for the solution for the audio drivers on your system not working after the upgrade, you find plenty of solutions. Nearly all of them appear to be rather complicated. Solutions to most problems in linux are rather trivial.
Knowing that the problems are caused by the 2.6 kernel changing over to ALSA from OSS, I figured upgrading my ALSA would solve my problem. After downloading the latest version from ..., indeed my speakers were happily jabbering away. However all is not good news after a restart I found that the sound system had not been reactivated.
Another visit to Google came up with a lot of different solutions. Most of them involved a script called rcalsasound, a script which is invoked by init. Unfortunately such a script wasn't available in my download bundle or on my cd collection or any of the other places I looked. Fortunately you don't need it. All you need to do is run alsactl store and then run alsactl restore after a reboot. It would save a lot of typing if you just added the last command to your init script (or even to your .bash_profile).
To recap here are the simple steps to reactivate your sound system after upgrading the kernel
- Download and compile the alsa drivers, libraries and utilities.
- run the snddevices script
- run alsaconf
- use aplay to playback some sound
Wouldn't it be nice if linux machines could hybernate just like windows machines seems to do? Indeed this is one of the attractions of switching to the 2.6 version of the kernel. However looking at the documentations for software suspend really put me off.
At first I wasn't too concerned about the dire warnings in the Documentation/sound/alsa file; I have read too many such warnings to bother. What I found disturbing is the following statement There are currently two versions of swap suspend in the kernel, the old "Pavel's" version in kernel/power/swsusp.c and the new "Patrick's" version in kernel/power/pmdisk.c. They provide the same functionality; the old version looks ugly but was tested, while the new version looks nicer but did not receive so much testing. ouch.
All in all, the only good thing about software suspend is that it can save you a few seconds at boot time. It may never amount to more than a couple of minutes each month. I might still have gone ahead with the SysVinit patch if it had been accompanied by a README. It wasn't so I am stuck with out a suspender. I suggest you put off any thoughts on hibernation until you are really sure that winter has arrived or the kernel and swsusp matures, which ever comes first.
On systems that make use of RPMs (Red hat Package Manager) you might find that you are no longer able to install or query the RPM db as root. (what's the use of user level access when many RPMS require root privileges?). You can of course upgrade your package manager and hope the problem goes away. Or you can add the following alias:
alias rpm='LD_ASSUME_KERNEL=2.2.5 rpm'
Do what ever you think will be easier ;-)
Part I : Upgrading to the 2.6.5 kernel