A. C. Censi wrote: > Bob Proulx wrote: > > One option that has worked for me in other similar but different > > situations is to move/remove the module from the filesystem. With it > > gone from the disk the kernel couldn't load it. That worked for me > > without needing to recompile the kernel without the module. > > Why not put a blacklist entry in /etc/modprobe.d? Use as a model > entries already there.
The answer to this question was in the part I quoted from and was responding to: A. F. Cano wrote: > It appears that the kernel insisted on loading this in preference to > other drivers and the sound hardware didn't work, even when I > blacklisted it and forcefully inserted the proper one. I presume that > by that time the resources had been marked as used, or initialized in > some way that made them unusable. As you can see I was well aware of the module blacklist functionality. It was used but did not prevent the problem. I can only add to the fud here by saying I have seen similar problems in the past. Even though the module was blacklisted this didn't seem to be enough to avoid the problem. Only by making sure that it was not possible to load the module could I avoid the problem. It appears by A. F. Cano's posting that I was not the only one with that issue. I do not know because I was not able to debug this to root cause but I will guess that there were scripts where the loading of the module was hard coded. I will guess that these scripts did not consult the blacklist. Again I do not know if any of those problems historically seen are still active today. Time goes by, old bugs are fixed, new bugs are created, and the world doesn't stay the same. I am not currently having any problems of this type but have moved on to more mainstream hardware too. Bob
signature.asc
Description: Digital signature
