begin: [EMAIL PROTECTED] <[EMAIL PROTECTED]> quote > On Mon, Jul 30, 2001 at 07:50:15AM -0700, Peter Jay Salzman wrote: > > if you can't remove the sound module with rmmod or modprobe, you will > need to > > reboot the system. > > a fuser -v /dev/dsp /dev/audio /dev/mixer may be helpful in > identifying and killing a process which is using the sound device and > tying up the module. > > i've also found on occasion, my sound drivers will get corrupted after > a suspend/resume on my laptop.
this isn't a driver getting corrupted. when a driver gets corrupted, your kernel gets corrupted. a reboot is necessary. you're talking about bad behavior on the _user_ side. not the _kernel_ side, which is where device drivers live. > fuser didn't show anything using the > device, but when i checked my processes, esd was sitting there pegging > the cpu. when i killed esd, i could remove and reinstall the sound > driver (maestro3) and sound would work again. > > i appreciated this solution instead of rebooting because it is just > fun to tell people you are tracking an uptime on your laptop. very true -- however, the original poster (you should've left the entire quote in, tsk tsk!) said that he had loaded the _wrong_ module. meaning that, somehow, the module was able to init but simply can't communicate with the kernel. probing hardware is a funny business. it's much more than conceivable that such an occurance will corrupt kernel code. in such a case, the module fails to load not because /dev/dsp is in use, but because of some other reason. perhaps the MODCOUNT gets lost. a pointer went wild. who knows? in that case, a reboot is much more than recommended. even if the system seems fine, the potential for true misery exists. pete -- "The following addresses had permanent fatal errors..." [EMAIL PROTECTED] -- Mailer Daemon www.dirac.org/p