Jon Masters wrote: > On Thu, 2010-03-04 at 20:28 +0200, Ozan Çağlayan wrote: >> Alan Jenkins wrote: >> >>>> That's what I'm doing actually from shell. >>> Try "modprobe -r" :-). >> I already tried it several times but wasn't successful at all. Will look at >> it again :) > > Can you provide more information? For example, are you trying to remove > a driver from a system configured without module unloading support? > Where the module is in use? etc.?
No of course not on a system without module unloading support. When debugging alsa-driver related stuff I generally need to simulate a clean boot where udev probes the sound-card related drivers so I want to remove all the linked-in snd-* modules and call: modprobe snd-hda-intel to try the new module(s). But I never succeeded to remove the pulled-in dependencies of snd-hda-intel with -r even after killing the apps which are currently using the related device nodes. So every time I manually remove the snd-* modules by looking at lsmod output (instead of writing a script:)) by starting from the ones with *0 used by* column. By removing them one by one, other snd-* modules' reference counts slowly drops to 0 and at the end I'm done: $(lsmod | grep snd) is empty. I googled a bit and find out the init script for alsasound (whether it's necessary or not is arguable) which does exactly what I tried to explain: http://bugs.gentoo.org/attachment.cgi?id=189127&action=view Shortly I think that m-i-t should track this pulled-in dependency chain and could be able to prune them all upon unloading. According to the manpage of modprobe, -r seems to handle this if the dependencies are not used too. Maybe it's just a missed use-case where the dependencies have refcount >= 0 and not refcount == 0. Regards, -- To unsubscribe from this list: send the line "unsubscribe linux-modules" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
