[mythtv-users] Cards keep changing /dev/videoX devices...

R. G. Newbury newbury at mandamus.org
Wed Jun 20 16:10:11 UTC 2007


Nick Morrott wrote:
> On 19/06/07, R. G. Newbury <newbury at mandamus.org> wrote:
>> Nick Morrott wrote:
>>> On 17/06/07, R. G. Newbury <newbury at mandamus.org> wrote:
>>>
>>>> So, what's the secret? How do you repeatably get ONLY the cx88_dvb
>>>> module loaded, without also taking explicit steps to stop the cx8800
>>>> module from being loaded.
>>>> (Being picky, I won't accept answers which involve the cx8800 module
>>>> being loaded at /dev/video2 (using the option line as in your prior
>>>> post) and then the cx88_dvb module being loaded at /dev/dvb/adapter0 etc.)
>>> One method that Fedora offers to control module loading is to put a
>>> file (with extension of .modules) in /etc/sysconfig/modules containing
>>> command you wanting executed early on in the boot process.
>>>
>>> If you create a file called /etc/sysconfig/modules/cx88.modules containing
>>>
>>> modprobe -r cx8800
>>> sleep 3
>>> modprobe cx88-dvb
>>>
>>> You should not have to blacklist the bad module (although this should
>>> stop it being loaded) or worry about the good module not being loaded.
>> Yet another way to achieve the same end situation!
>> These same three lines would work just as well in rc.local (although I
>> suspect that the sysconfig file will be parsed and run earlier in boot.
> 
> The 'yet another' way I mention - altering a single .modules file -
> should ensure drivers have finished loading before system services and
> daemons that require them (like mythbackend or lircd for example)
> start. This is the whole point of the /etc/sysconfig/modules
> framework.
> 
> If a user has any module loading/unloading in rc.local they should
> seriously look into using  a different mechanism - such as those
> mentioned in this thread - to handle their modules. Otherwise, you can
> easily end up with a rc.local full of modprobes and 'service start
> xxx' lines which are better handles elsewhere.
> 
That last, is a good point. Between us, we have mentioned 4 methods of 
controlling the load order. There is another too: deleting or renaming 
the offending module (in this case the cx8800 module).

All of this discussion has been predicated on the assumption that the 
user does NOT want the NTSC module (cx8800) loaded. If the user wants 
that module but wants specific device assignments where the cx8800 
modules is NOT assigned at /dev/video0, then it will be necessary to use 
the blacklist together with another method, in order to control the 
device assignments. That was the problem which the OP had run into: 
'wrong' device assingments. It is still unclear why his device 
assignments were unstable, as distinct to merely having the 'wrong' 
order. But that may just have been as simple as a card being slow to 
react from a cold start. As from that sort of problem, device 
assignments are deterministic, its just that we might not understand why 
we received the determination we got!


If you do not want to use the NTSC capability of your card, the easiest 
route is actually to rename/delete the module. However, that can cause a 
weird WTF problem when you upgrade and forget what you have done because 
you will get a new version of the module with your new kernel....

Secondly, and probably next in the boot order, in terms of activity, is 
to blacklist the module. That just stops the kernel from choosing it 
during startup. It remains available for explicit load commands, and is 
unaffected by updates. One line in one file.

Third, use /etc/sysconfig/modules. This is good if you need certain 
modules loaded so that services can access them later. Again, loading is 
explicitly ordered by the user, which is probably sufficient to stablize 
device assignments.

Fourth, use option lines in modprobe,conf, If the module has been 
blacklisted, it can be installed at this point together with using the 
option to control the device assignment (which not be necessary if the 
'other' module is loaded first.

Finally, use rc.local. This runs last and, as pointed out, should be the 
last resort, especially as it might require 'service restart' commands.

And I wouldn't call using any of these methods a 'sledgehammer' approach 
compared to any other method. They all have their advantages and 
disadvantages.

And thanks Nick for the info about modinfo...

Geoff



More information about the mythtv-users mailing list