Order of dvb devices

Order of dvb devices

[Andreas Besse]

if a system contains multiple DVB cards of the same type, how is the
order of devices determined by the driver/kernel?

I use 2 Technotrend S2-3200 cards in a system and observerd that if I
load the driver driver budget_ci manually as follows:

modprobe budget_ci adapter_nr=0,1

the device with the lower pci ID 0000:08:00.0 is assigned to adapter0 and the device with the higher pci ID 0000:08:01.0
is assigned to adapter1:


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"


udevinfo -a -p $(udevinfo -q path -n /dev/dvb/adapter1/frontend0)
[...]
  looking at parent device '/devices/pci0000:00/0000:00:1e.0/0000:08:01.0':
    KERNELS=="0000:08:01.0"
    SUBSYSTEMS=="pci"


Is it true for all DVB drives that the device with the lower PCI id gets the lower adapter name?

Re: Order of dvb devices

[Devin Heitmueller]

On Thu, Jan 14, 2010 at 10:35 AM, Andreas Besse <besse@motama.com> wrote:
> if a system contains multiple DVB cards of the same type, how is the
> order of devices determined by the driver/kernel?
>
> I use 2 Technotrend S2-3200 cards in a system and observerd that if I
> load the driver driver budget_ci manually as follows:
>
> modprobe budget_ci adapter_nr=0,1
>
> the device with the lower pci ID 0000:08:00.0 is assigned to adapter0 and the device with the higher pci ID 0000:08:01.0
> is assigned to adapter1:
>
>
> 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"
>
>
> udevinfo -a -p $(udevinfo -q path -n /dev/dvb/adapter1/frontend0)
> [...]
>  looking at parent device '/devices/pci0000:00/0000:00:1e.0/0000:08:01.0':
>    KERNELS=="0000:08:01.0"
>    SUBSYSTEMS=="pci"
>
>
> Is it true for all DVB drives that the device with the lower PCI id gets the lower adapter name?

No, you cannot really make this assumption.  In fact, there are users
who see behavior where uses have two of the same card and the cards
get flipped around randomly just by rebooting.  The ordering is based
on the timing of the device driver loading, so it is not
deterministic.

I believe you can use udev rules though to force a particular driver
to get a specific adapter number (although admittedly I do not know
the specifics of how it is done, and am not confident it *can* be done
if both cards are the same vendor/model).

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

Re: Order of dvb devices

[Andreas Besse]

Devin Heitmueller wrote:
> On Thu, Jan 14, 2010 at 10:35 AM, Andreas Besse <besse@motama.com> wrote:
>   
>> if a system contains multiple DVB cards of the same type, how is the
>> order of devices determined by the driver/kernel?
>>
>> I use 2 Technotrend S2-3200 cards in a system and observerd that if I
>> load the driver driver budget_ci manually as follows:
>>
>> modprobe budget_ci adapter_nr=0,1
>>
>> the device with the lower pci ID 0000:08:00.0 is assigned to adapter0 and the device with the higher pci ID 0000:08:01.0
>> is assigned to adapter1:
>>
>>
>> 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"
>>
>>
>> udevinfo -a -p $(udevinfo -q path -n /dev/dvb/adapter1/frontend0)
>> [...]
>>  looking at parent device '/devices/pci0000:00/0000:00:1e.0/0000:08:01.0':
>>    KERNELS=="0000:08:01.0"
>>    SUBSYSTEMS=="pci"
>>
>>
>> Is it true for all DVB drives that the device with the lower PCI id gets the lower adapter name?
>>     
>
> No, you cannot really make this assumption.  In fact, there are users
> who see behavior where uses have two of the same card and the cards
> get flipped around randomly just by rebooting.  The ordering is based
> on the timing of the device driver loading, so it is not
> deterministic.
>   
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?

Re: Order of dvb devices

[Devin Heitmueller]

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?

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".

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

Re: Order of dvb devices

[Michael Krufky]

On Thu, Jan 14, 2010 at 11:09 AM, Devin Heitmueller
<dheitmueller@kernellabs.com> 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?
>
> 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".
>
> Devin
>
> --
> Devin J. Heitmueller - Kernel Labs
> http://www.kernellabs.com
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

If you "modinfo dvb_adapter_driver_foo"  you will see an "adapter_nr"
module option -- you can use this to force your DVB adapter device
minor ordering.

Regards,

Mike

Re: Order of dvb devices

[Oliver Endriss]

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.

CU
Oliver

-- 
----------------------------------------------------------------
VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/
Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/
----------------------------------------------------------------

Re: Order of dvb devices

[Devin Heitmueller]

On Fri, Jan 15, 2010 at 6:00 PM, Oliver Endriss <o.endriss@gmx.de> wrote:
>> 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.

I suppose it's possible that udev does not process the events in the
order in which they are received.  Admittedly I have not done any real
analysis as to how that part of the kernel works.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

Re: Order of dvb devices

[Manu Abraham]

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.



Regards,
Manu

Re: Order of dvb devices

[hermann pitton]

Am Samstag, den 16.01.2010, 00:00 +0100 schrieb Oliver Endriss:
> 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.
> 
> CU
> Oliver
> 

Agreed.

Hermann

Re: Order of dvb devices

[Mika Laitio]

> 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.

At least in Mandriva, the order and naming of network adapters are 
handled by using a this kind of udev rule which prevents for example eth0 
and eth1 to swap between boots:

[lamikr@iiris rules.d]$ cat 70-persistent-net.rules
# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.

# Drakx-net rule for eth0 (00:24:e8:9e:66:13)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", 
ATTR{address}=="00:11:22:33:44:55", ATTR{type}=="1", KERNEL=="eth*", 
NAME="eth0

# PCI device 0x8086:0x4232 (iwlagn)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", 
ATTR{address}=="11:22:33:44:55:66", ATTR{type}=="1", KERNEL=="wlan*", 
NAME="wlan0""

I am not sure whether udev rules itself can originally generate this file 
or whether it's mandriva's own tools/scripts that will generate this file 
and add all new adapters it finds that are not yet in the file.

Mika

Re: Order of dvb devices

[Andreas Besse]

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?

Re: Order of dvb devices

[Manu Abraham]

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

Regards,
Manu

Re: Order of dvb devices

[Andreas Besse]

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"

Re: Order of DVB devices

[Andreas Besse]

Kay Sievers wrote:
> On Tue, Jan 26, 2010 at 16:22, Greg KH <greg@kroah.com> wrote:
>   
>> On Tue, Jan 26, 2010 at 03:36:39PM +0100, Andreas Besse wrote:
>>     
>>> i have a system with multiple DVB cards of the same type and want to
>>> specify the order of the devices /dev/dvb/adapterX. The device plugged
>>> into the physical PCI slot 1 on the mainboard should be assigned to
>>> /dev/dvb/adapter0 and the card in PCI slot 2 should be assigned to
>>> /dev/dvb/adapter1.
>>>       
>
> We usually do not change kernel names, but create meaningful named
> symlinks to them. Stuff gets confused when /sys and /dev get
> out-of-sync.
>
>   
>>> In the following post
>>> http://thread.gmane.org/gmane.linux.kernel.pci/7446/focust67 there
>>> is mentioned that the order of the devices can be specified by using
>>> udev rules.
>>>       
>
> The order can usually only specified by unconditionally loading kernel
> driver modules in a defined order. This usually works fine for PCI
> devices, but can obviously not work if there are USB devices involved.
>
>   
>>> But how this can be done? Which information in /sys can be used to
>>> determine which DVB device is connected to which specific slot?
>>>       
>> Did you try the latest version of udev that has the persistant rules for
>> the v4l devices in it and look at the symlinks that are created to see
>> if they solve the problem for you?
>>     
>
> Looking at it now, I think we only do video4linux, not the DVB stuff,
> which has its own class. But it should be possible to implement a
> similar model for /dev/dvb/by-id, /dev/dvb/by-path without much
> problems. It's just, that nobody really cared so far.
>
> Thanks,
> Kay
>   

but how can these persistent rules solve the issue that the order of PCI Slots (PCI Bus IDs) is not deterministic and totally random determined at boot?

I think the udev rules only can use informations which are already available in /sys/ ?


regards,
Andreas Besse

Re: Order of DVB devices

[Kay Sievers]

On Tue, Jan 26, 2010 at 16:22, Greg KH <greg@kroah.com> wrote:
> On Tue, Jan 26, 2010 at 03:36:39PM +0100, Andreas Besse wrote:
>> i have a system with multiple DVB cards of the same type and want to
>> specify the order of the devices /dev/dvb/adapterX. The device plugged
>> into the physical PCI slot 1 on the mainboard should be assigned to
>> /dev/dvb/adapter0 and the card in PCI slot 2 should be assigned to
>> /dev/dvb/adapter1.

We usually do not change kernel names, but create meaningful named
symlinks to them. Stuff gets confused when /sys and /dev get
out-of-sync.

>> In the following post
>> http://thread.gmane.org/gmane.linux.kernel.pci/7446/focust67 there
>> is mentioned that the order of the devices can be specified by using
>> udev rules.

The order can usually only specified by unconditionally loading kernel
driver modules in a defined order. This usually works fine for PCI
devices, but can obviously not work if there are USB devices involved.

>> But how this can be done? Which information in /sys can be used to
>> determine which DVB device is connected to which specific slot?
>
> Did you try the latest version of udev that has the persistant rules for
> the v4l devices in it and look at the symlinks that are created to see
> if they solve the problem for you?

Looking at it now, I think we only do video4linux, not the DVB stuff,
which has its own class. But it should be possible to implement a
similar model for /dev/dvb/by-id, /dev/dvb/by-path without much
problems. It's just, that nobody really cared so far.

Thanks,
Kay

Re: Order of DVB devices

[Greg KH]

On Tue, Jan 26, 2010 at 03:36:39PM +0100, Andreas Besse wrote:
> Hello,
> 
> i have a system with multiple DVB cards of the same type and want to
> specify the order of the devices /dev/dvb/adapterX. The device plugged
> into the physical PCI slot 1 on the mainboard should be assigned to
> /dev/dvb/adapter0 and the card in PCI slot 2 should be assigned to
> /dev/dvb/adapter1.
> 
> To identify a DVB card I looked at the output of udevinfo for 2 DVB
> devices. The devices don't provide a serial, so the difference is only
> in the KERNELS parameter (e.g. KERNELS="0000:02:00.0" vs.
> KERNELS="0000:03:00.0"). The Kernels parameter seem to reflect the PCI
> Bus ID.
> 
> According to the thread
> http://thread.gmane.org/gmane.linux.kernel.pci/7446/focust47 on the
> linux-pci mailinglist, the PCI Bus ID is *not* deterministic and
> totally random determined at boot. 
> 
> In the following post
> http://thread.gmane.org/gmane.linux.kernel.pci/7446/focust67 there
> is mentioned that the order of the devices can be specified by using
> udev rules.
> 
> But how this can be done? Which information in /sys can be used to
> determine which DVB device is connected to which specific slot?

Did you try the latest version of udev that has the persistant rules for
the v4l devices in it and look at the symlinks that are created to see
if they solve the problem for you?

thanks,

greg k-h

Order of DVB devices

[Andreas Besse]

Hello,

i have a system with multiple DVB cards of the same type and want to
specify the order of the devices /dev/dvb/adapterX. The device plugged
into the physical PCI slot 1 on the mainboard should be assigned to
/dev/dvb/adapter0 and the card in PCI slot 2 should be assigned to
/dev/dvb/adapter1.

To identify a DVB card I looked at the output of udevinfo for 2 DVB
devices. The devices don't provide a serial, so the difference is only
in the KERNELS parameter (e.g. KERNELS="0000:02:00.0" vs.
KERNELS="0000:03:00.0"). The Kernels parameter seem to reflect the PCI
Bus ID.

According to the thread http://thread.gmane.org/gmane.linux.kernel.pci/7446/focust47 on the linux-pci mailinglist, the PCI Bus ID is *not* deterministic and totally random determined at boot. 

In the following post http://thread.gmane.org/gmane.linux.kernel.pci/7446/focust67 there is mentioned that the order of the devices can be specified by using udev rules.

But how this can be done? Which information in /sys can be used to determine which DVB device is connected to which specific slot?

regards,
Andreas Besse

Re: Order of dvb devices

[Dan Taylor]

Mika Laitio wrote:
>> 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.
>
> At least in Mandriva, the order and naming of network adapters are handled by using a this kind of udev rule which prevents for example eth0 and eth1 to swap between boots:
>
> [lamikr@iiris rules.d]$ cat 70-persistent-net.rules
> # This file was automatically generated by the /lib/udev/write_net_rules
> # program, run by the persistent-net-generator.rules rules file.
> #
> # You can modify it, as long as you keep each rule on a single
> # line, and change only the value of the NAME= key.
>
> # Drakx-net rule for eth0 (00:24:e8:9e:66:13)
> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:11:22:33:44:55", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0
>
> # PCI device 0x8086:0x4232 (iwlagn)
> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="11:22:33:44:55:66", ATTR{type}=="1", KERNEL=="wlan*", NAME="wlan0""
>
> I am not sure whether udev rules itself can originally generate this file or whether it's mandriva's own tools/scripts that will generate this file and add all new adapters it finds that are not yet in the file.
>
> Mika


The eth drivers have one advantage:  nearly all of them have an
associated MAC address, which is (supposed to be, anyway) globally
(the planet, not just the system) unique.  It is, therefore, easy
enough to associate a specific NIC with a specific name, as shown.

If we keep some sort of configuration table:

For those boards that have eeproms, and for which the eeprom contains
a serial number, or other unique identifier, we could do the same thing.

Alternatively, we could use the PCI address (bus/device/unit).

USB devices can have serial numbers, but it isn't common.

Sounds like we need to think about keeping a table, having some udev
rules to work with it, and some utility to manage it.

RFQ time?

> -- 
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>