Hi list, By trying to compile a new alsa-driver-1.0.19 from source on a machine with a generic Debian kernel 2.6.24 including ALSA driver 1.0.16, I recently managed to trash ALSA on that machine. I had been optimistic by just doing to usual configure/make/make install without caring about the existing ALSA driver. This resulted in the following error message when trying to load the snd_hdsp module aftrwards: FATAL: Error inserting snd_hdsp (/lib/modules/2.6.24-1-686/kernel/sound/pci/rme9652/snd-hdsp.ko): Unknown symbol in module, or unknown parameter (see dmesg) FATAL: Error running install command for snd_hdsp And here is the output of dmesg: snd_hwdep: disagrees about version of symbol snd_info_register snd_hwdep: Unknown symbol snd_info_register snd_hwdep: disagrees about version of symbol snd_info_create_module_entry snd_hwdep: Unknown symbol snd_info_create_module_entry snd_hwdep: disagrees about version of symbol snd_info_free_entry snd_hwdep: Unknown symbol snd_info_free_entry snd_hwdep: disagrees about version of symbol snd_unregister_oss_device snd_hwdep: Unknown symbol snd_unregister_oss_device snd_hwdep: Unknown symbol snd_verbose_printk snd_hwdep: disagrees about version of symbol snd_register_oss_device [... and so on for many more symbols...] This output suggests to me that there were still remains of the old 1.0.16 driver floating around, causing a versioning conflict. What measures can be taken before compiling the new driver in order to avoid this situation? Or in other words: do I need to get rid of the ALSA driver that came with a generic kernel before compiling a new one, and if so, how do I do it? best, flo.H P.S.: I also found this: http://alsa.opensrc.org/index.php/TroubleShooting#When_loading_modules.2C_i…. but unfortunately cannot check 'lsmod', since I have purged the respective kernel :-(