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

[R. G. Newbury]

Alan Calvert wrote:
> R. G. Newbury wrote:
>> Steve Smith wrote:
>>> Alan,
>>>
>>> Great! Nice and simple...
>>>
>>> I do like the idea of a udev "freeze/dump current config" type feature,
>>> that'd be really useful for the generic case...
>>>
>>> Cheers
>>>
>>> Steve
>>>
>>> On 14/06/07, Alan Calvert <cal at graggrag.com> wrote:
>>>> Steve Smith wrote:
>>>>> I have two cards in my system; a PVR-150 and a WinFast DTV-1000T.
>>>>>
>>>>> The devices work "OK", but every reboot get assigned /dev/video0 and
>>>>> /dev/video1 in a random order so the myth config keeps getting
>>>>> messed up.
>>>>>
>>>>> Is there anyway to stabilise them?
>>>> Messing with udev rules to control this is unnecessary, and overly
>>>> complicated. Most of the driver modules take a parameter to specify
>>>> what device it should use when modprobed. With ivtv, it's
>>>> 'ivtv_first_minor',
>>>> and with cx8800 (the DTV-1000) it's  video_nr and radio_nr. Try
>>>> 'modinfo ivtv' and 'modinfo cx8800' (as root) for the full list of
>>>> options .
>>>>
>>>> I have the same mix of cards in my system, two DTV-1000's actually,
>>>> and in a file /etc/modprobe.d/mythtv I have ...
>>>>     options cx8800 video_nr=0,1 radio_nr=0,1 vbi_nr=0,1
>>>>     options ivtv pal=BG ivtv_first_minor=2
>>>> So the two DTV1000s are always /dev/video0, /dev/video1, and the
>>>> PVR-150 always comes up as /dev/video2 (and friends).
>>>>
>>>> Simple as that. Cheers!
>> You should also understand that the cx88 driver is built into the 
>> kernel, and will be called/installed before the ivtv driver is 
>> called/installed. And the 'wrong' cx88 driver might be the one the 
>> kernel installs, as it hasn't yet looked at modprobe.conf.


> No offence, but that's nonsense. It would be _most_ unusual for the
> cx88 driver to be built into the kernel. More likely, the kernel is
> autoloading the module having discovered the video card and identified
> the appropriate driver module for it.
>  

Writing too late at night. You are precise and I was not. Of course the 
module is not 'built in' to the kernel. What IS built in, is that the 
kernel can recognize the hardware, and then automagically loads a module.

The killer detail is that the kernel loads what IT thinks is 
"appropriate". In my case with a HD3000 it always wanted to load the 
cx8800 module (instead of the cx88_dvb module I wanted). And the cx8800 
module grabbed /dev/video0 which messed up where the ivtv driver got to 
put the PVR500 outputs.

>> This causes problems where an HD3000 is being used for digital. You 
>> wouldn't want the cx8800 driver (and /dev/video0 being stolen). You 
>> would want the cx88_dvb driver being loaded instead. The answer is to 
>> blacklist the driver you do NOT want (or ALL of them), and remove 
>> drivers, if necessary, from modprobe.conf, and load your drivers in 
>> order, in rc.local.
>>
>> So, for my setup, I blacklisted cx8800 and cx88_dvb, and then loaded 
>> cx88_dvb by a line in rc.local. The PVR500 then gets /dev/video1 and 
>> video2, through the ivtv driver, and there will be nothing in the way, 
>> and that is the first driver call to latch onto that spot.
>>
>> In your case, the cx8800 driver is likely being loaded by the kernel as 
>> soon as the hardware is recognized. But your modprobe.conf is likely set 
>> up on the assumption that the ivtv driver will be called first (you 
>> listed it first, and computers *ALWAYS* do exactly what we want, and in 
>> the order we want...right? Right?).
> 
> Again, half-baked nonsense. If your video device allocations are explicitly
> set in modprobe.conf (or other related module config files) then regardless
> of how or when the video driver module gets loaded - kernel autoload,
> /etc/modules, rc.local, whererever/whenever - the assignment of video device
> numbers will _always_ be as specified by your options settings. 

Perfectly baked and not nonsense. You presume that the kernel will ONLY 
load things 'as specified by your options settings'. In fact that is not 
true, *using only modprobe.conf* unless other things are done explicitly 
to control the modules which are loaded.

I spent far too much time after upgrading from FC5 to FC6 proving to my 
  satisfaction that the kernel could not be trusted to load what I 
wanted *without being explicitly told*. And that telling required 
blacklisting the cx8800 module or unloading everything 'cx' related in 
rc.local, and reloading what I wanted. (I did both).

>> You might want to try commenting out everything in modprobe.conf and see 
>> what ends loaded. Then try 'modprobe -r cx8800' in rc.local and see if 
>> anything at all is loaded. Then try the ivtv lines in modprobe.conf. And 
>> finally, try a 'modprobe cx8800' in rc.local.
>>
>> I would bet (a small wager!) that the last is a stable result.
> 
> Yep, blacklisting everything and ordering the module loads explicitly in
> rc.local works, as does using a sledgehammer to crack a nut. Simply allocating
> video device numbers explicitly by means of module options also works.
> 
> No desire for argument here, but some of the advice presented was simply false
> and misleading.

Nothing false. I'll put my hand up for being misleading about the module 
being 'built into' the kernel.

There are NO module options for the cx8800 which allow you to force it 
to a specific video device, as there is for the ivtv driver. The only 
control method is load order. So you have to know what is being loaded 
and where. If cx8800 is loaded early, then ivtv won't be the first. If 
you do not want cx8800, there is an available option to tell the system 
"Don't do that!" It is the blacklist.

If you want stabile placement, you must force the loading to occur in a 
specific order. That requires commands which are outside using 
modprobe.conf. Modprobe.conf lines alone are not sufficient (unless you 
can uninstall in modprobe.conf and I don't know how to do that). Using 
rc.local is not a 'sledgehammer' nor is using the blacklist. Either 
method provides a clean state from which to commence loading what you 
want in the order you want.

Do you even have this hardware? Have you played with it to see whether 
you get *repeatably* get only the cx88_dvb module to load, *without* 
also taking explicit steps to stop cx8800 from being loaded?



              R. Geoffrey Newbury			

        Helping with the HTTP issue
<a href="http://www.w3.org/Protocols/">HTTP</a>