Re: Side Question Regarding Modules (Related to Sound Server ?)
On Mi, 23 feb 11, 13:53:53, Hugo Vanwoerkom wrote: > > How in the world did you figure out tthat unplugging the mouse would > resolve a sound conflict? I got lucky :) I don't recall exactly what triggered it, but a while ago I realized that the sound would break only when that mouse is connected. Since I'm not using it I've had no more sound issues. I was tracking this issue for years (no kidding). Because this is a headless machine (if you don't count the TV) it was running without a mouse most of times. Only on occasion I would connect the only spare mouse (PS/2), but I never made the connection to the sound issues. Regards, Andrei -- Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic signature.asc Description: Digital signature
Re: Side Question Regarding Modules (Related to Sound Server ?)
Andrei Popescu wrote: On Mi, 23 feb 11, 05:35:15, teddi...@tmo.blackberry.net wrote: I was thinking about the reply I read to the restarting sound server question suggesting removing the modules and re inserting them, forgive me author of that post, I forget who suggested it... Anyway I having not attempted this method before was thinking about how to go about it. I would assume an # lsmod That would involve at least some guesswork. 'lspci -v' also shows the kernel driver used for the specific device (not only for the sound card). Would give you the names of your targeted modules and one would follow with # modprobe -r ModName && # modprobe ModName Yes But upon reading the man page for modprobe I get the felling the use of modprobe is intended for long term management of modules to be loaded and unloaded in kernel upon boot, e.g. You remove module for sound but fail to properly reload it and you system is fubar upon reboot. Should this be a concern with this method? Is modprobe the suggested method for this type of action or are their commands I'm not thinking/familure with for said purpose?? I will dare to say that if modprobe fails to reinsert the module something is *seriously* wrong with the system (hardware and/or software). The only problems I have encountered so far with this approach: # modprobe -r snd-hda-intel FATAL: Module snd_hda_intel is in use. 'lsof | grep snd' will help find out what is using it. On another machine, the sound would suddenly just start distorting and removing and reinserting the module had no effect, the only way to get it back to normal was a power cycle. I eventually got rid of the problem when I unplugged the PS2 mouse so I assume it was a hardware conflict. How in the world did you figure out tthat unplugging the mouse would resolve a sound conflict? Hugo -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/ik3okh$euu$1...@dough.gmane.org
Re: Side Question Regarding Modules (Related to Sound Server ?)
On Mi, 23 feb 11, 05:35:15, teddi...@tmo.blackberry.net wrote: > > I was thinking about the reply I read to the restarting sound server > question suggesting removing the modules and re inserting them, > forgive me author of that post, I forget who suggested it... > > Anyway I having not attempted this method before was thinking about > how to go about it. I would assume an > > # lsmod That would involve at least some guesswork. 'lspci -v' also shows the kernel driver used for the specific device (not only for the sound card). > Would give you the names of your targeted modules and one would follow with > > # modprobe -r ModName > > && > > # modprobe ModName Yes > But upon reading the man page for modprobe I get the felling the use > of modprobe is intended for long term management of modules to be > loaded and unloaded in kernel upon boot, e.g. You remove module for > sound but fail to properly reload it and you system is fubar upon > reboot. Should this be a concern with this method? Is modprobe the > suggested method for this type of action or are their commands I'm not > thinking/familure with for said purpose?? I will dare to say that if modprobe fails to reinsert the module something is *seriously* wrong with the system (hardware and/or software). The only problems I have encountered so far with this approach: # modprobe -r snd-hda-intel FATAL: Module snd_hda_intel is in use. 'lsof | grep snd' will help find out what is using it. On another machine, the sound would suddenly just start distorting and removing and reinserting the module had no effect, the only way to get it back to normal was a power cycle. I eventually got rid of the problem when I unplugged the PS2 mouse so I assume it was a hardware conflict. HTH, Andrei -- Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic signature.asc Description: Digital signature
Side Question Regarding Modules (Related to Sound Server ?)
I was thinking about the reply I read to the restarting sound server question suggesting removing the modules and re inserting them, forgive me author of that post, I forget who suggested it... Anyway I having not attempted this method before was thinking about how to go about it. I would assume an # lsmod Would give you the names of your targeted modules and one would follow with # modprobe -r ModName && # modprobe ModName But upon reading the man page for modprobe I get the felling the use of modprobe is intended for long term management of modules to be loaded and unloaded in kernel upon boot, e.g. You remove module for sound but fail to properly reload it and you system is fubar upon reboot. Should this be a concern with this method? Is modprobe the suggested method for this type of action or are their commands I'm not thinking/familure with for said purpose?? Thanks; TeddyB -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1585995524-1298439316-cardhu_decombobulator_blackberry.rim.net-19639700...@bda029.bisx.prod.on.blackberry
