udev problem DVB-S/T Cards

udev problem DVB-S/T Cards

[Razza]

All,
I have been playing with udev as I need to pin specific identical DVB cards
to specific nodes, mixing DVB-S and DVB-T is bad!
I have found how to identify cards etc. but getting the rule right is
confusing me. I am running Fedora Core 5 and have the following standard
rule in "/etc/udev/rules.d/50-udev.rules" -

SUBSYSTEM="dvb", PROGRAM="/bin/sh -c 'K=%k; K=$${K#dvb}; printf
dvb/adapter%%i/%%s $${K%%%%.*} $${K#*.}'", NAME="%c", MODE="0660"
 
The closest I got to getting things working was by substituting
"dvb/adapter%%i/" with "dvb/adapter5/", thus forcing the adapter to
/dev/dvb/adapter5, rule below -

BUS="pci", ID="0000:01:06.0", SYSFS{device}="0x7146",
SYSFS{vendor}="0x1131", PROGRAM="/bin/sh -c 'K=%k; K=$${K#dvb}; printf
dvb/adapter5/%%s $${K%%%%.*} $${K#*.}'", NAME="%c", MODE="0660"

Unfortunately that changed the tree/node structure from the norm -
 /dev/dvb/
 `-- adapter5
     |-- ca0
     |-- demux0
     |-- dvr0
     |-- frontend0
     `-- net0
 
To -
 
 /dev/dvb/
 `-- adapter5
     |-- 0dvb
     |   `-- adapter5
     |       |-- ca0
     |       |-- demux0
     |       |-- dvr0
     |       |-- frontend0
     |       `-- net0
     `-- event3dvb
         `-- adapter5
             `-- event3
 
I think the problem I am having is that the original rule is based on the
top section of my "udevinfo -a -p $(udevinfo -q path -n
/dev/dvb/adapter0/frontend0)" response, my rule is based on the second
section, thus introducing additional layers as it's further down the
hardware/kernel stack?

My "udevinfo -a -p $(udevinfo -q path -n /dev/dvb/adapter0/frontend0)"
response is as follows -

  looking at device '/class/dvb/dvb0.frontend0':
    KERNEL="dvb0.frontend0"
    SUBSYSTEM="dvb"
    SYSFS{dev}="212:3"

  looking at device '/devices/pci0000:00/0000:00:10.0/0000:01:06.0':
    ID="0000:01:06.0"
    BUS="pci"
    DRIVER="budget_ci dvb"
    SYSFS{msi_bus}=""
    SYSFS{broken_parity_status}="0"
    SYSFS{enable}="1"
    SYSFS{modalias}="pci:v00001131d00007146sv000013C2sd00001017bc04sc80i00"
    SYSFS{local_cpus}="1"
    SYSFS{irq}="18"
    SYSFS{class}="0x048000"
    SYSFS{subsystem_device}="0x1017"
    SYSFS{subsystem_vendor}="0x13c2"
    SYSFS{device}="0x7146"
    SYSFS{vendor}="0x1131"

  looking at device '/devices/pci0000:00/0000:00:10.0':
    ID="0000:00:10.0"
    BUS="pci"
    DRIVER=""
    SYSFS{msi_bus}="1"
    SYSFS{broken_parity_status}="0"
    SYSFS{enable}="1"
    SYSFS{modalias}="pci:v000010DEd0000026Fsv00000000sd00000000bc06sc04i01"
    SYSFS{local_cpus}="1"
    SYSFS{irq}="0"
    SYSFS{class}="0x060401"
    SYSFS{subsystem_device}="0x0000"
    SYSFS{subsystem_vendor}="0x0000"
    SYSFS{device}="0x026f"
    SYSFS{vendor}="0x10de"

Can anyone advise of the correct rule?

Thanks in advance!



-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

RE: udev problem DVB-S/T Cards

[Razza]

Razza wrote on 28 April 2007 11:49:
> All,
> I have been playing with udev as I need to pin specific identical DVB
> cards
> to specific nodes, mixing DVB-S and DVB-T is bad!
> I have found how to identify cards etc. but getting the rule right is
> confusing me. I am running Fedora Core 5 and have the following
> standard
> rule in "/etc/udev/rules.d/50-udev.rules" -
> 
> SUBSYSTEM="dvb", PROGRAM="/bin/sh -c 'K=%k; K=$${K#dvb}; printf
> dvb/adapter%%i/%%s $${K%%%%.*} $${K#*.}'", NAME="%c", MODE="0660"
> 
> The closest I got to getting things working was by substituting
> "dvb/adapter%%i/" with "dvb/adapter5/", thus forcing the adapter to
> /dev/dvb/adapter5, rule below -
> 
> BUS="pci", ID="0000:01:06.0", SYSFS{device}="0x7146",
> SYSFS{vendor}="0x1131", PROGRAM="/bin/sh -c 'K=%k; K=$${K#dvb}; printf
> dvb/adapter5/%%s $${K%%%%.*} $${K#*.}'", NAME="%c", MODE="0660"
> 
> Unfortunately that changed the tree/node structure from the norm -
>  /dev/dvb/
>  `-- adapter5
>      |-- ca0
>      |-- demux0
>      |-- dvr0
>      |-- frontend0
>      `-- net0
> 
> To -
> 
>  /dev/dvb/
>  `-- adapter5
>      |-- 0dvb
>      |   `-- adapter5
>      |       |-- ca0
>      |       |-- demux0
>      |       |-- dvr0
>      |       |-- frontend0
>      |       `-- net0
>      `-- event3dvb
>          `-- adapter5
>              `-- event3
> 
> I think the problem I am having is that the original rule is based on
> the
> top section of my "udevinfo -a -p $(udevinfo -q path -n
> /dev/dvb/adapter0/frontend0)" response, my rule is based on the second
> section, thus introducing additional layers as it's further down the
> hardware/kernel stack?
> 
> My "udevinfo -a -p $(udevinfo -q path -n /dev/dvb/adapter0/frontend0)"
> response is as follows -
> 
>   looking at device '/class/dvb/dvb0.frontend0':
>     KERNEL="dvb0.frontend0"
>     SUBSYSTEM="dvb"
>     SYSFS{dev}="212:3"
> 
>   looking at device '/devices/pci0000:00/0000:00:10.0/0000:01:06.0':
>     ID="0000:01:06.0"
>     BUS="pci"
>     DRIVER="budget_ci dvb"
>     SYSFS{msi_bus}=""
>     SYSFS{broken_parity_status}="0"
>     SYSFS{enable}="1"
> 
> SYSFS{modalias}="pci:v00001131d00007146sv000013C2sd00001017bc04sc80i00
> "
>     SYSFS{local_cpus}="1"
>     SYSFS{irq}="18"
>     SYSFS{class}="0x048000"
>     SYSFS{subsystem_device}="0x1017"
>     SYSFS{subsystem_vendor}="0x13c2"
>     SYSFS{device}="0x7146"
>     SYSFS{vendor}="0x1131"
> 
>   looking at device '/devices/pci0000:00/0000:00:10.0':
>     ID="0000:00:10.0"
>     BUS="pci"
>     DRIVER=""
>     SYSFS{msi_bus}="1"
>     SYSFS{broken_parity_status}="0"
>     SYSFS{enable}="1"
> 
> SYSFS{modalias}="pci:v000010DEd0000026Fsv00000000sd00000000bc06sc04i01
> "
>     SYSFS{local_cpus}="1"
>     SYSFS{irq}="0"
>     SYSFS{class}="0x060401"
>     SYSFS{subsystem_device}="0x0000"
>     SYSFS{subsystem_vendor}="0x0000"
>     SYSFS{device}="0x026f"
>     SYSFS{vendor}="0x10de"
> 
> Can anyone advise of the correct rule?
> 
> Thanks in advance!

I havn't seen any responses to this, so I guess no one else can help? 
Can you please advise how I can dump information out (to say a text file)
when the udev rules run?
I am specifically interested in what 'K' is at various points in this rule -


BUS="pci", ID="0000:01:06.0", SYSFS{device}="0x7146",
SYSFS{vendor}="0x1131", PROGRAM="/bin/sh -c 'K=%k; K=$${K#dvb}; printf
dvb/adapter5/%%s $${K%%%%.*} $${K#*.}'", NAME="%c", MODE="0660"



-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: udev problem DVB-S/T Cards

[Bryan Kadzban]

[-- Attachment #1.1: Type: text/plain, Size: 1113 bytes --]

Razza wrote:
> I am specifically interested in what 'K' is at various points in this
> rule -
> 
> 
> BUS=="pci", ID=="0000:01:06.0", SYSFS{device}=="0x7146", 
> SYSFS{vendor}=="0x1131", PROGRAM="/bin/sh -c 'K=%k; K=$${K#dvb};
> printf dvb/adapter5/%%s $${K%%%%.*} $${K#*.}'", NAME="%c",
> MODE="0660"

Well, it starts out at %k (the kernel NAME, which should be available
via udevinfo).  After that, you should be able to set K=<that name> in a
normal shell, and then start running subsequent commands from the shell,
while echoing $K from time to time.

(However, note that udev requires double dollar signs and double percent
signs, so if you paste the various echos and printfs into a shell,
you'll have to un-escape those characters.  I.e., %%s should be run
through the shell as %s, and %%%% should be turned into %%.)

And actually, K only changes once (when it's set to ${K#dvb} just before
the printf.  The rest of that rule is just formatting the output.

(Oh, and you hopefully already know this from the documentation, but
NAME="%c" sets NAME to the output of the PROGRAM.)


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

[-- Attachment #2: Type: text/plain, Size: 286 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

[-- Attachment #3: Type: text/plain, Size: 226 bytes --]

_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

RE: udev problem DVB-S/T Cards

[Razza]

Bryan Kadzban wrote on 02 May 2007 12:08:
> Razza wrote:
> > I am specifically interested in what 'K' is at various points in this
> > rule -
> >
> >
> > BUS="pci", ID="0000:01:06.0", SYSFS{device}="0x7146",
> > SYSFS{vendor}="0x1131", PROGRAM="/bin/sh -c 'K=%k; K=$${K#dvb};
> > printf dvb/adapter5/%%s $${K%%%%.*} $${K#*.}'", NAME="%c",
> MODE="0660"
> 
> Well, it starts out at %k (the kernel NAME, which should be available
> via udevinfo).  After that, you should be able to set K=<that name> in
> a normal shell, and then start running subsequent commands from the
> shell, while echoing $K from time to time.
> 
> (However, note that udev requires double dollar signs and double
> percent signs, so if you paste the various echos and printfs into a
> shell, you'll have to un-escape those characters.  I.e., %%s should be
> run through the shell as %s, and %%%% should be turned into %%.)
> 
> And actually, K only changes once (when it's set to ${K#dvb} just
> before the printf.  The rest of that rule is just formatting the
> output.
> 
> (Oh, and you hopefully already know this from the documentation, but
> NAME="%c" sets NAME to the output of the PROGRAM.)
Ah!
So a udevinfo yields kernels names such as - KERNEL="dvb1.frontend0"
So I guess I need to change the K=$${K#dvb} element to only return the
correct nodes so I end up with a correctly formatted tree?


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: udev problem DVB-S/T Cards

[Matthias Schwarzott]

On Samstag, 28. April 2007, Razza wrote:
> All,
> I have been playing with udev as I need to pin specific identical DVB cards
> to specific nodes, mixing DVB-S and DVB-T is bad!
> I have found how to identify cards etc. but getting the rule right is
> confusing me. I am running Fedora Core 5 and have the following standard
> rule in "/etc/udev/rules.d/50-udev.rules" -
>
> SUBSYSTEM="dvb", PROGRAM="/bin/sh -c 'K=%k; K=$${K#dvb}; printf
> dvb/adapter%%i/%%s $${K%%%%.*} $${K#*.}'", NAME="%c", MODE="0660"
>
Some time ago I also tried this. But it will end up like persistent-net then. 
You need good criteria to name the devices. Else it will only be chaos.
And most apps does not work with holes in the numbering as they just open 
devices starting from 0, until open fails.

Example:

Having /dev/dvb0/ /dev/dvb1/ /dev/dvb2/ and then unplugging the device 
formerly named dvb1. then you stay with devices dvb0 and dvb2.

The rule I would simply split into some more lines like:


SUBSYSTEM!="dvb", GOTO="dvb_end"
ACTION!="add", GOTO="dvb_end"

GROUP="video"
import{PROGRAM}="/bin/sh -c 'K=%k; K=$${K#dvb}; echo 
ID_DVB_ADAPTER_KERNEL=$${K%%%%.*}; echo ID_DVB_DEVICE=$${K#*.}'"

IMPORT{program}="path_id %p"

#Here set ID_DVB_ADAPTER to be persistent
# example:
ENV{ID_PATH}="pci-0000:00:0b.0-", ENV{ID_DVB_ADAPTER}="0"
ENV{ID_PATH}="pci-0000:00:0a.0-", ENV{ID_DVB_ADAPTER}="1"

# fallback-number
ENV{ID_DVB_ADAPTER_KERNEL}="?*", ENV{ID_DVB_ADAPTER}!="?*", 
ENV{ID_DVB_ADAPTER}="$env{ID_DVB_ADAPTER_KERNEL}"

# Create device
ENV{ID_DVB_ADAPTER}="?*", ENV{ID_DVB_DEVICE}="?*", 
NAME="dvb/adapter$env{ID_DVB_ADAPTER}/$env{ID_DVB_DEVICE}"


LABEL="dvb_end"

But this is untested.

The same problem will appear with all other devices being just numbered, like 
video and audio devices.

The simplest solution is to just blacklist the drivers from autoloading, and 
then load them in predefined/known order.

Matthias

-- 
Matthias Schwarzott (zzam)

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: udev problem DVB-S/T Cards

[Matthias Schwarzott]

On Mittwoch, 2. Mai 2007, Matthias Schwarzott wrote:
> On Samstag, 28. April 2007, Razza wrote:
> > All,
> > I have been playing with udev as I need to pin specific identical DVB
> > cards to specific nodes, mixing DVB-S and DVB-T is bad!
> > I have found how to identify cards etc. but getting the rule right is
> > confusing me. I am running Fedora Core 5 and have the following standard
> > rule in "/etc/udev/rules.d/50-udev.rules" -
> >
> > SUBSYSTEM="dvb", PROGRAM="/bin/sh -c 'K=%k; K=$${K#dvb}; printf
> > dvb/adapter%%i/%%s $${K%%%%.*} $${K#*.}'", NAME="%c", MODE="0660"
>
> Some time ago I also tried this. But it will end up like persistent-net
> then. You need good criteria to name the devices. Else it will only be
> chaos. And most apps does not work with holes in the numbering as they just
> open devices starting from 0, until open fails.

>
> SUBSYSTEM!="dvb", GOTO="dvb_end"
> ACTION!="add", GOTO="dvb_end"
>
> GROUP="video"
> import{PROGRAM}="/bin/sh -c 'K=%k; K=$${K#dvb}; echo
> ID_DVB_ADAPTER_KERNEL=$${K%%%%.*}; echo ID_DVB_DEVICE=$${K#*.}'"
>
> IMPORT{program}="path_id %p"
>
> #Here set ID_DVB_ADAPTER to be persistent
> # example:
> ENV{ID_PATH}="pci-0000:00:0b.0-", ENV{ID_DVB_ADAPTER}="0"
> ENV{ID_PATH}="pci-0000:00:0a.0-", ENV{ID_DVB_ADAPTER}="1"
>
> # fallback-number
> ENV{ID_DVB_ADAPTER_KERNEL}="?*", ENV{ID_DVB_ADAPTER}!="?*",
> ENV{ID_DVB_ADAPTER}="$env{ID_DVB_ADAPTER_KERNEL}"
>
> # Create device
> ENV{ID_DVB_ADAPTER}="?*", ENV{ID_DVB_DEVICE}="?*",
> NAME="dvb/adapter$env{ID_DVB_ADAPTER}/$env{ID_DVB_DEVICE}"
>
>
> LABEL="dvb_end"
>
> But this is untested.
>
> The same problem will appear with all other devices being just numbered,
> like video and audio devices.
>
> The simplest solution is to just blacklist the drivers from autoloading,
> and then load them in predefined/known order.
>

I think I forgot the part that you need to change path_id to accept 
dvb-devices. This was just a small change, but I dont have it on my disk 
right now.

Matthias

-- 
Matthias Schwarzott (zzam)

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

RE: udev problem DVB-S/T Cards

[Razza]

Matthias Schwarzott wrote on 02 May 2007 13:37:
> Some time ago I also tried this. But it will end up like persistent-net
> then.
> You need good criteria to name the devices. Else it will only be chaos.
> And most apps does not work with holes in the numbering as they just
> open
> devices starting from 0, until open fails.
> 
------------------8< SNIP! >8------------------
> 
> But this is untested.

The DVB section of my /etc/udev/rules.d/50-udev.rules is now as follows:

# DVB
KERNEL="dvb",                  MODE="0660"
SUBSYSTEM!="dvb", GOTO="dvb_end"
ACTION!="add", GOTO="dvb_end"

GROUP="video"
import{PROGRAM}="/bin/sh -c 'K=%k; K=$${K#dvb}; echo
ID_DVB_ADAPTER_KERNEL=$${K%%%%.*}; echo ID_DVB_DEVICE=$${K#*.}'"

IMPORT{program}="path_id %p"

#Here set ID_DVB_ADAPTER to be persistent # example:
ENV{ID_PATH}="pci-0000:01:08.0", ENV{ID_DVB_ADAPTER}="3"
ENV{ID_PATH}="pci-0000:01:06.0", ENV{ID_DVB_ADAPTER}="2"

# fallback-number
ENV{ID_DVB_ADAPTER_KERNEL}="?*", ENV{ID_DVB_ADAPTER}!="?*",
ENV{ID_DVB_ADAPTER}="$env{ID_DVB_ADAPTER_KERNEL}"

# Create device
ENV{ID_DVB_ADAPTER}="?*", ENV{ID_DVB_DEVICE}="?*",
NAME="dvb/adapter$env{ID_DVB_ADAPTER}/$env{ID_DVB_DEVICE}"

LABEL="dvb_end"

So, i'm assuming with the changes the nodes should be /dev/dvb/adapter2/ and
/dev/dvb/adapter3/ ?
Unfortunately they are still being loaded as /dev/dvb/adapter0/ and
/dev/dvb/adapter1/

udevinfo -a -p $(udevinfo -q path -n /dev/dvb/adapter0/frontend0) gives the
following:

login as: root
root@192.168.10.138's password:
Last login: Wed May  2 22:28:32 2007 from 192.168.10.188
[root@MythBE ~]# udevinfo -a -p $(udevinfo -q path -n
/dev/dvb/adapter0/frontend0)

udevinfo starts with the device the node belongs to and then walks up the
device chain, to print for every device found, all possibly useful
attributes
in the udev key format.
Only attributes within one device section may be used together in one rule,
to match the device for which the node will be created.

  looking at device '/class/dvb/dvb0.frontend0':
    KERNEL="dvb0.frontend0"
    SUBSYSTEM="dvb"
    SYSFS{dev}="212:3"

  looking at device '/devices/pci0000:00/0000:00:10.0/0000:01:08.0':
    ID="0000:01:08.0"
    BUS="pci"
    DRIVER="budget dvb"
    SYSFS{msi_bus}=""
    SYSFS{broken_parity_status}="0"
    SYSFS{enable}="1"
    SYSFS{modalias}="pci:v00001131d00007146sv000013C2sd00001005bc04sc80i00"
    SYSFS{local_cpus}="1"
    SYSFS{irq}="21"
    SYSFS{class}="0x048000"
    SYSFS{subsystem_device}="0x1005"
    SYSFS{subsystem_vendor}="0x13c2"
    SYSFS{device}="0x7146"
    SYSFS{vendor}="0x1131"

  looking at device '/devices/pci0000:00/0000:00:10.0':
    ID="0000:00:10.0"
    BUS="pci"
    DRIVER=""
    SYSFS{msi_bus}="1"
    SYSFS{broken_parity_status}="0"
    SYSFS{enable}="1"
    SYSFS{modalias}="pci:v000010DEd0000026Fsv00000000sd00000000bc06sc04i01"
    SYSFS{local_cpus}="1"
    SYSFS{irq}="0"
    SYSFS{class}="0x060401"
    SYSFS{subsystem_device}="0x0000"
    SYSFS{subsystem_vendor}="0x0000"
    SYSFS{device}="0x026f"
    SYSFS{vendor}="0x10de"

  looking at device '/devices/pci0000:00':
    ID="pci0000:00"
    BUS=""
    DRIVER=""

udevinfo -a -p $(udevinfo -q path -n /dev/dvb/adapter1/frontend0) gives the
following:

  looking at device '/class/dvb/dvb1.frontend0':
    KERNEL="dvb1.frontend0"
    SUBSYSTEM="dvb"
    SYSFS{dev}="212:67"

  looking at device '/devices/pci0000:00/0000:00:10.0/0000:01:06.0':
    ID="0000:01:06.0"
    BUS="pci"
    DRIVER="budget_ci dvb"
    SYSFS{msi_bus}=""
    SYSFS{broken_parity_status}="0"
    SYSFS{enable}="1"
    SYSFS{modalias}="pci:v00001131d00007146sv000013C2sd00001017bc04sc80i00"
    SYSFS{local_cpus}="1"
    SYSFS{irq}="20"
    SYSFS{class}="0x048000"
    SYSFS{subsystem_device}="0x1017"
    SYSFS{subsystem_vendor}="0x13c2"
    SYSFS{device}="0x7146"
    SYSFS{vendor}="0x1131"

  looking at device '/devices/pci0000:00/0000:00:10.0':
    ID="0000:00:10.0"
    BUS="pci"
    DRIVER=""
    SYSFS{msi_bus}="1"
    SYSFS{broken_parity_status}="0"
    SYSFS{enable}="1"
    SYSFS{modalias}="pci:v000010DEd0000026Fsv00000000sd00000000bc06sc04i01"
    SYSFS{local_cpus}="1"
    SYSFS{irq}="0"
    SYSFS{class}="0x060401"
    SYSFS{subsystem_device}="0x0000"
    SYSFS{subsystem_vendor}="0x0000"
    SYSFS{device}="0x026f"
    SYSFS{vendor}="0x10de"

  looking at device '/devices/pci0000:00':
    ID="pci0000:00"
    BUS=""
    DRIVER=""

Have I missed something?


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: udev problem DVB-S/T Cards

[Bryan Kadzban]

[-- Attachment #1.1: Type: text/plain, Size: 394 bytes --]

Razza wrote:
> Have I missed something?

You need to add support for DVB devices to path_id, but other than that
I don't think so.

After you add support (or if you already have), then you will want to
make sure the right ID_PATH value is printed by path_id when run
manually.  You will need to give path_id the devpath of the device file
(which is what "udevinfo -q path" prints).


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

[-- Attachment #2: Type: text/plain, Size: 286 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

[-- Attachment #3: Type: text/plain, Size: 226 bytes --]

_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

RE: udev problem DVB-S/T Cards

[Razza]

Bryan Kadzban wrote on 02 May 2007 23:21:
> Razza wrote:
> > Have I missed something?
> 
> You need to add support for DVB devices to path_id, but other than that
> I don't think so.
> 
> After you add support (or if you already have), then you will want to
> make sure the right ID_PATH value is printed by path_id when run
> manually.  You will need to give path_id the devpath of the device file
> (which is what "udevinfo -q path" prints).

Sorry I am not a Linux expert, in fact definitely rank of super newbie!
I have to put my hands up and say, I really don't understand what you are
saying :o(
Is the path/node not set by this command ?
NAME="dvb/adapter$env{ID_DVB_ADAPTER}/$env{ID_DVB_DEVICE}"


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: udev problem DVB-S/T Cards

[Bryan Kadzban]

[-- Attachment #1.1: Type: text/plain, Size: 1333 bytes --]

Razza wrote:
> I have to put my hands up and say, I really don't understand what you
> are saying :o(

Just that you (probably unintentionally) ignored one thing that Matthias
said[1] -- the path_id script doesn't have support for DVB devices (at
this point).  It needs to have support added before this set of rules
will work correctly.

> Is the path/node not set by this command ? 
> NAME="dvb/adapter$env{ID_DVB_ADAPTER}/$env{ID_DVB_DEVICE}"

Yes, it is -- but that rule will use the wrong value for ID_DVB_ADAPTER
and _DEVICE.  Because path_id won't print anything for these devices,
ENV{ID_PATH} will be empty (normally path_id creates it).  And therefore
neither ID_DVB_ADAPTER-setting rule will ever match.

Therefore, the rules will use the fall-back values (which aren't any
different than before).

To fix the problem, you'd have to add DVB support to /lib/udev/path_id
-- but I don't know what the devpath looks like for DVB devices, so I
don't know how you'd do that for sure.  I suspect you only have to add a
"dvb" entry to the case statement near the bottom of the file (make it
look just like the others), because once that's recognized, it *should*
use the already-present PCI-bus code.  But I can't test that myself.

[1] http://marc.info/?l=linux-hotplug-devel&m=117811269801775&w=2


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

[-- Attachment #2: Type: text/plain, Size: 286 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

[-- Attachment #3: Type: text/plain, Size: 226 bytes --]

_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

RE: udev problem DVB-S/T Cards

[Razza]

Bryan Kadzban wrote on 03 May 2007 02:56:
-------------8< Snip! >8-------------
> Just that you (probably unintentionally) ignored one thing that
> Matthias said[1] -- the path_id script doesn't have support for DVB
> devices (at this point).  It needs to have support added before this
> set of rules will work correctly.

TBH, I did pick up on Matthias' statement about path-id, in fact I mailed
him back to say i'll wait till he finds the other bits (path-id) as I can do
without breaking anything else on my machine. 
Note to self: Do not use force options on an array after you have loaded all
your media!

I then re-read the message and thought maybe he simply meant the following
statement needed adding for each device: ENV{ID_PATH}="pci-0000:00:0b.0-",
ENV{ID_DVB_ADAPTER}="0" , which I duly did.

-------------8< Snip! >8-------------
> To fix the problem, you'd have to add DVB support to /lib/udev/path_id
> -- but I don't know what the devpath looks like for DVB devices, so I
> don't know how you'd do that for sure.  I suspect you only have to add
> a "dvb" entry to the case statement near the bottom of the file (make
> it look just like the others), because once that's recognized, it
> *should* use the already-present PCI-bus code.  But I can't test that
> myself.

I can now see where you are coming from as: IMPORT{program}="path_id %p" is
calling the path_id script.
I have located path_id which is in /sbin on Fedora core 5, there are some
pretty long case statements in there (one I counted had 47 lines!), the
simplest and last I could find is - 

case "$TYPE" in
        block)
        handle_block
        ;;
        *)
        RESULT=1
        ;;
esac

I have been trying to walk through some sections of this file for the last
couple of hours and have to admit, I am totally out of my depth. I'm not
even sure if I have the right path_id file, the commented section at the top
of path_id states "provide the shortest possible unique hardware path to a
block device for the udev persistent disk device naming scheme" - clearly
i'm not playing with block devices.

Can anyone provide the necessary case section I need, or is there any info I
can give which would help? Hell i'll even donate a DVB-T card to someone.


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: udev problem DVB-S/T Cards

[Bryan Kadzban]

[-- Attachment #1.1: Type: text/plain, Size: 2074 bytes --]

Razza wrote:
> I have located path_id which is in /sbin on Fedora core 5

Hmm; it should be in /lib/udev AFAIK.  But maybe this doesn't matter.

> there are some pretty long case statements in there (one I counted
> had 47 lines!),

Yeah, it's complicated.  But I don't think we can do much about that...

> the simplest and last I could find is -
> 
> case "$TYPE" in
>         block)
>         handle_block
>         ;;
>         *)
>         RESULT=1
>         ;;
> esac

That should be the right case, but that doesn't look like the current
version of the script.  The script from udev-110 looks like this:

case "$TYPE" in
    block)
        handle_device
        echo "ID_PATH=$d"
        ;;
    scsi_tape)
        handle_device
        echo "ID_PATH=$d"
        ;;
    input)
        handle_device
        echo "ID_PATH=$d"
        ;;
    *)
        RESULT=1
        ;;
esac

And then it's followed by:

exit $RESULT

But I don't think it's safe to modify the script that you have unless it
has a case that matches this layout (because the script you have is
quite different from mine, so I don't think my modifications are valid
for your system).  Is it possible to get an updated udev?  I know that
the path_id script from udev-105 should work with the changes I posted
last night, and I know -110 should too, so I assume anything between
those two should also work.

(But use a distro version of udev, not the sources.  The sources will
put the path_id script in /lib/udev, and it sounds like your distro
already has that script somewhere else.  There will probably be other
issues too.)

> I'm not even sure if I have the right path_id file, the commented
> section at the top of path_id states "provide the shortest possible
> unique hardware path to a block device for the udev persistent disk
> device naming scheme" - clearly i'm not playing with block devices.

No, but that is the right script.  :-)  When it was first created, it
only handled block devices, but other stuff can be added.


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

[-- Attachment #2: Type: text/plain, Size: 286 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

[-- Attachment #3: Type: text/plain, Size: 226 bytes --]

_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

RE: udev problem DVB-S/T Cards

[Razza]

Bryan Kadzban wrote on 03 May 2007 12:13:
> Razza wrote:
> > I have located path_id which is in /sbin on Fedora core 5
> Hmm; it should be in /lib/udev AFAIK.  But maybe this doesn't matter.
Wouldn't be the first time something is in a completely different place in
Fedora!

> > there are some pretty long case statements in there (one I counted had
47 lines!),
> Yeah, it's complicated.  But I don't think we can do much about that...
:o) Agree - The user (me) needs to get more intelligent!

----------8< snip! >8----------

> That should be the right case, but that doesn't look like the current
> version of the script.  The script from udev-110 looks like this:
> 
> case "$TYPE" in
>     block)
>         handle_device
>         echo "ID_PATH=$d"
>         ;;
>     scsi_tape)
>         handle_device
>         echo "ID_PATH=$d"
>         ;;
>     input)
>         handle_device
>         echo "ID_PATH=$d"
>         ;;
>     *)
>         RESULT=1
>         ;;
> esac
> 
> And then it's followed by:
> 
> exit $RESULT
> 
> But I don't think it's safe to modify the script that you have unless
> it has a case that matches this layout (because the script you have is
> quite different from mine, so I don't think my modifications are valid
> for your system).  Is it possible to get an updated udev?  I know that
> the path_id script from udev-105 should work with the changes I posted
> last night, and I know -110 should too, so I assume anything between
> those two should also work.

Interestingly also in the commented out section of path_id it states (and
remember this is Fedora 5) :
# Copyright (C) 2005 SUSE Linux Products GmbH
# Author: Hannes Reinecke <hare@suse.de>

> (But use a distro version of udev, not the sources.  The sources will
> put the path_id script in /lib/udev, and it sounds like your distro
> already has that script somewhere else.  There will probably be other
> issues too.)

----------8< snip! >8----------

I have looked at the (rpm) version of udev, running my system:
udev-084-13.fc5.2.i386
Which appears to be the latest, see -
http://rpmfind.net/linux/rpm2html/search.php?query=udev-persistent
The build date is "Build date: Wed Aug 16 17:19:57 2006" - could try forcing
the FC6 or 7 rpm's? 


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: udev problem DVB-S/T Cards

[Matthias Schwarzott]

[-- Attachment #1: Type: text/plain, Size: 2061 bytes --]

On Donnerstag, 3. Mai 2007, Razza wrote:
> Bryan Kadzban wrote on 03 May 2007 12:13:
> > Razza wrote:
> > > I have located path_id which is in /sbin on Fedora core 5
> >
> > Hmm; it should be in /lib/udev AFAIK.  But maybe this doesn't matter.
>
> Wouldn't be the first time something is in a completely different place in
> Fedora!
>
> > > there are some pretty long case statements in there (one I counted had
>
> 47 lines!),
>
> > Yeah, it's complicated.  But I don't think we can do much about that...
> >
> :o) Agree - The user (me) needs to get more intelligent!
>
> ----------8< snip! >8----------
>
> > That should be the right case, but that doesn't look like the current
> > version of the script.  The script from udev-110 looks like this:
> >
> > case "$TYPE" in
> >     block)
> >         handle_device
> >         echo "ID_PATH=$d"
> >         ;;
> >     scsi_tape)
> >         handle_device
> >         echo "ID_PATH=$d"
> >         ;;
> >     input)
> >         handle_device
> >         echo "ID_PATH=$d"
> >         ;;
> >     *)
> >         RESULT=1
> >         ;;
> > esac

Yes, this is the case-statement I changed last time.
As I did not have my changes (deleted long ago) I needed to redo it. Result is 
attached. The only change is duplicating one of those statementes.

By the way: why isnt there just
case "$TYPE" in
  block|scsi_tape|input)
    ...
    ;;
  *)
esac
as the code is the same in every place?

The reason for no longer doing this, is that I talked to linuxtv guys, and 
they told me they do not support such stuff :(

And well, to make it general applicable you need a good scheme to identify the 
cards.
A. by path: like above, fails with usb devices
B. by pci ids: fails with multiple identical cards, or with switching 
card-slots
Need to be improved for cards with multiple dvb-adapters (twin-tuner and 
similar)

C. by serial: some devices have serial numbers like usb, but not all


I just switched back to blacklisting all dvb-modules, and load them in well 
known order.

Matthias

-- 
Matthias Schwarzott (zzam)

[-- Attachment #2: path_id-dvb.diff --]
[-- Type: text/x-diff, Size: 259 bytes --]

--- /lib/udev/path_id.old	2007-05-03 14:03:39.000000000 +0200
+++ /lib/udev/path_id	2007-05-03 14:04:08.000000000 +0200
@@ -549,6 +549,10 @@
 		handle_device
 		echo "ID_PATH=$d"
 		;;
+	dvb)
+		handle_device
+		echo "ID_PATH=$d"
+		;;
 	*)
 		RESULT=1
 		;;

[-- Attachment #3: Type: text/plain, Size: 286 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

[-- Attachment #4: Type: text/plain, Size: 226 bytes --]

_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

RE: udev problem DVB-S/T Cards

[Razza]

Matthias Schwarzott wrote on 03 May 2007 13:14:
> Yes, this is the case-statement I changed last time.
> As I did not have my changes (deleted long ago) I needed to redo it.
> Result is attached. The only change is duplicating one of those
> statementes.
> 
> By the way: why isnt there just
> case "$TYPE" in
>   block|scsi_tape|input)
>     ...
>     ;;
>   *)
> esac
> as the code is the same in every place?
> 
> The reason for no longer doing this, is that I talked to linuxtv guys,
> and they told me they do not support such stuff :(
> 
> And well, to make it general applicable you need a good scheme to
> identify the cards.
> A. by path: like above, fails with usb devices B. by pci ids: fails
> with multiple identical cards, or with switching card-slots Need to be
> improved for cards with multiple dvb-adapters (twin-tuner and
> similar)
> 
> C. by serial: some devices have serial numbers like usb, but not all
> 
> I just switched back to blacklisting all dvb-modules, and load them in
> well known order.

Matthias thanks for the work you have done, do I simply paste the contents
of your file into my path_id file?


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

RE: udev problem DVB-S/T Cards

[Razza]

Razza wrote on 07 May 2007 18:19:
> Matthias Schwarzott wrote on 03 May 2007 13:14:
> > Yes, this is the case-statement I changed last time.
> > As I did not have my changes (deleted long ago) I needed to redo it.
> > Result is attached. The only change is duplicating one of those
> > statementes.
> >
---------8< SNIP! >8---------
> > I just switched back to blacklisting all dvb-modules, and load them
> in
> > well known order.
> 
> Matthias thanks for the work you have done, do I simply paste the
> contents
> of your file into my path_id file?


I don't think the diff file will work with my version of path_id, firstly as
the directory for path_id on my system is in /sbin, even if I point patch at
the right file it errors.
So from the .diff file, what is the correct format which should appear in
/sbin/path_id, I will manually type it (probably cut and paste!).

The contents of the .diff file is:
--- /lib/udev/path_id.old	2007-05-03 14:03:39.000000000 +0200
+++ /lib/udev/path_id	2007-05-03 14:04:08.000000000 +0200
@@ -549,6 +549,10 @@
 		handle_device
 		echo "ID_PATH=$d"
 		;;
+	dvb)
+		handle_device
+		echo "ID_PATH=$d"
+		;;
 	*)
 		RESULT=1
 		;;

Thanks again!

If you could provide me with advice on "blacklisting all dvb-modules, and
loading them in well known order." Off list that would be great too, I just
want my system to work!





-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

RE: udev problem DVB-S/T Cards

[Razza]

Razza wrote on 09 May 2007 18:50
> Razza wrote on 07 May 2007 18:19:
> > Matthias Schwarzott wrote on 03 May 2007 13:14:
> > > Yes, this is the case-statement I changed last time.
> > > As I did not have my changes (deleted long ago) I needed to redo
> it.
> > > Result is attached. The only change is duplicating one of those
> > > statementes.
> > >
> ---------8< SNIP! >8---------
> > > I just switched back to blacklisting all dvb-modules, and load them
> > in
> > > well known order.
> >
> > Matthias thanks for the work you have done, do I simply paste the
> > contents
> > of your file into my path_id file?
> 
> 
> I don't think the diff file will work with my version of path_id,
> firstly as
> the directory for path_id on my system is in /sbin, even if I point
> patch at
> the right file it errors.
> So from the .diff file, what is the correct format which should appear
> in
> /sbin/path_id, I will manually type it (probably cut and paste!).
> 
> The contents of the .diff file is:
> --- /lib/udev/path_id.old	2007-05-03 14:03:39.000000000 +0200
> +++ /lib/udev/path_id	2007-05-03 14:04:08.000000000 +0200
> @@ -549,6 +549,10 @@
>  		handle_device
>  		echo "ID_PATH=$d"
>  		;;
> +	dvb)
> +		handle_device
> +		echo "ID_PATH=$d"
> +		;;
>  	*)
>  		RESULT=1
>  		;;
> 
> Thanks again!
> 
> If you could provide me with advice on "blacklisting all dvb-modules,
> and
> loading them in well known order." Off list that would be great too, I
> just
> want my system to work!
Can you please advise what the path_id file should look like, as the diff
fails for me?


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

RE: udev problem DVB-S/T Cards

[Razza]

All,
I am still struggling to get my DVB cards to load appropriately. 
My DVB section of /etc/udev/rules.d/50-udev.rules is as follows - 

################################# /etc/udev/rules.d/50-udev.rules
############################### # DVB
KERNEL="dvb",                  MODE="0660"
SUBSYSTEM!="dvb", GOTO="dvb_end"
ACTION!="add", GOTO="dvb_end"

GROUP="video"
import{PROGRAM}="/bin/sh -c 'K=%k; K=$${K#dvb}; echo
ID_DVB_ADAPTER_KERNEL=$${K%%%%.*}; echo ID_DVB_DEVICE=$${K#*.}'"

IMPORT{program}="path_id %p"

#Here set ID_DVB_ADAPTER to be persistent # example:
ENV{ID_PATH}="pci-0000:01:08.0", ENV{ID_DVB_ADAPTER}="3"
ENV{ID_PATH}="pci-0000:01:06.0", ENV{ID_DVB_ADAPTER}="2"

# fallback-number
ENV{ID_DVB_ADAPTER_KERNEL}="?*", ENV{ID_DVB_ADAPTER}!="?*",
ENV{ID_DVB_ADAPTER}="$env{ID_DVB_ADAPTER_KERNEL}"

# Create device
ENV{ID_DVB_ADAPTER}="?*", ENV{ID_DVB_DEVICE}="?*",
NAME="dvb/adapter$env{ID_DVB_ADAPTER}/$env{ID_DVB_DEVICE}"

LABEL="dvb_end"
############################# 50-udev.rules END ############################

I have updated the final section of /sbin/path_id from - 

############################# path_id ############################ 
case "$TYPE" in
        block)
        handle_block
        ;;
        *)
        RESULT=1
        ;;
esac
############################# path_id END ############################

To the following, as the diff file Matthias sent me simply didn't work
(which I am sure is a case of Fedora just being different to gentoo which I
guess he is using) - 
############################# path_id ############################ 
case "$TYPE" in
        block)
        handle_block
        ;;
        dvb)
        handle_device
        echo "ID_PATH=$d"
        ;;
        *)
        RESULT=1
        ;;
esac
############################# path_id END ############################

Unfortunately the dvb adaptors still load as 0 and 1 as opposed to 2 and 3
as expected.
I have now tried this on Fedora 7 (as opposed to core 6 as I was
historically) and still get the same response.
HELP! 


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel