Re: Order of dvb devices

[Andreas Besse <besse@motama.com>]

Manu Abraham wrote:
> On Mon, Jan 18, 2010 at 12:58 PM, Andreas Besse <besse@motama.com> wrote:
>   
>> Manu Abraham wrote:
>>     
>>> On Sat, Jan 16, 2010 at 3:00 AM, Oliver Endriss <o.endriss@gmx.de> wrote:
>>>
>>>       
>>>> Devin Heitmueller wrote:
>>>>
>>>>         
>>>>> On Thu, Jan 14, 2010 at 11:01 AM, Andreas Besse <besse@motama.com> wrote:
>>>>>
>>>>>           
>>>>>> yes if there are different drivers I already observed the behaviour that
>>>>>> the ordering gets flipped after reboot.
>>>>>>
>>>>>> But if I assume, that there is only *one* driver that is loaded (e.g.
>>>>>> budget_av) for all dvb cards in the system, how is the ordering of these
>>>>>> devices determined? How does the driver "search" for available dvb cards?
>>>>>>
>>>>>>             
>>>> The driver does not 'search' for a card. The driver registers the ids of
>>>> all supported cards with the pci subsystem of the kernel.
>>>>
>>>> When the pci subsystem detects a new card, it calls the 'probe' routine
>>>> of the driver (for example saa7146_init_one for saa7146-based cards).
>>>> So the ordering is determined by the pci subsystem.
>>>>
>>>>
>>>>         
>>>>> I believe your assumption is incorrect.  I believe the enumeration
>>>>> order is not deterministic even for multiple instances of the same
>>>>> driver.  It is not uncommon to hear mythtv users complain that "I have
>>>>> two PVR-150 cards installed in my PC and the order sometimes get
>>>>> reversed on reboot".
>>>>>
>>>>>           
>>>> Afaik the indeterministic behaviour is caused by udev, not by the
>>>> kernel. We never had these problems before udev was introduced.
>>>>
>>>>         
>>> True, the ordering is not exactly the same everytime. One will need to
>>> provide PCI Bus related info also to a practical udev configuration to
>>> get things sorted out in a sane way, rather than anything else.
>>>
>>>       
>> with "PCI Bus related info" you mean the KERNELS parameter which is
>> reported by udevinfo?
>>
>> udevinfo -a -p $(udevinfo -q path -n /dev/dvb/adapter0/frontend0)
>> [...]
>>  looking at parent device '/devices/pci0000:00/0000:00:1e.0/0000:08:00.0':
>>    KERNELS=="0000:08:00.0"
>>    SUBSYSTEMS=="pci"
>>
>> does this KERNELS parameter always match the Slot-Id of "lspci -vmm" ?
>> Slot:   08:00.0
>> Class:  Multimedia controller
>> Vendor: Philips Semiconductors
>> Device: SAA7146
>> SVendor:        Technotrend Systemtechnik GmbH
>> SDevice:        S2-3200
>> Rev:    01
>>
>> is it right that the Slot-Id is deterministic for PCI/PCIe based systems?
>>     
>
>
> Slot can also change, since slots are behind a specific bridge which
> could be susceptible to events such as hotplug.  Also things such as
> PCI reordering and things like that tend to muck up things even
> more.Things such as DVB_ADAPTER number are also pointless and useless.
>
> You can see an example how to handle it in a bit practical manner:
> http://www.wlug.org.nz/UDev
> thanks for your explanation.
>
>   
thank for your answer.

if no hotplug (removing or adding PCI/PCie cards) is involved, is the
PCI Slot-ID then fixed?

does the KERNELS parameter of the following udev rule not change after
boot if no hotplug is involved?

SUBSYSTEM=="dvb", ATTRS{vendor}=="0x18c3", ATTRS{device}=="0x0720",
KERNELS=="0000:01:00.0",
PROGRAM="/bin/sh -c 'K=%k; K=$${K#dvb}; printf dvb/adapter0/%%s
$${K#*.}'", SYMLINK+="%c"