* Re: Loading firmware
2008-10-13 22:17 Loading firmware Jasem Mutlaq
@ 2008-10-14 0:18 ` Dan Nicholson
2008-10-14 13:16 ` Jasem Mutlaq
` (9 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: Dan Nicholson @ 2008-10-14 0:18 UTC (permalink / raw)
To: linux-hotplug
On Mon, Oct 13, 2008 at 3:17 PM, Jasem Mutlaq <mutlaqja@ikarustech.com> wrote:
> Hello,
>
> I need to load firmware to a USB camera via fxload. The problem is that
> fxload requires a path such as /dev/bus/usb/001/002 in order to load the
> firmware. So I wrote a udev rules file to do just that, however, the only
> useful variable I can obtain now is %k, and I get something in the form of
> usbdev1.2_ep00 which I then need to parse in some regexp magic in order to
> extract the bus and dev num in order to construct the full path. I used to
> be able to pull devnum and busnum ($env{BUSNUM}) but not anymore (using
> openSUSE 11). Now I have a loader script that parses %k and constructs the
> path. But this is only a hack and not a real solution, is there a way to get
> the full path so I can pass it to fxload without resorting to these
> desperate measures? Appreciate your help.
Does something like this help:
<some test to determine your device>, ACTION="add", RUN+="/sbin/fxload
-D /dev/$name"
Where $name points to the device name and will be set earlier by the
default rules.
--
Dan
^ permalink raw reply [flat|nested] 12+ messages in thread* RE: Loading firmware
2008-10-13 22:17 Loading firmware Jasem Mutlaq
2008-10-14 0:18 ` Dan Nicholson
@ 2008-10-14 13:16 ` Jasem Mutlaq
2008-10-14 14:33 ` Kay Sievers
` (8 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: Jasem Mutlaq @ 2008-10-14 13:16 UTC (permalink / raw)
To: linux-hotplug
> Does something like this help:
>
> <some test to determine your device>, ACTION="add", RUN+="/sbin/fxload
> -D /dev/$name"
>
> Where $name points to the device name and will be set earlier by the
> default rules.
It didn't work. The $name that I get is in the form of usbdev1.8_ep00 still. However, I tried the following
BUS="usb", ACTION="add", <...etc...> , ENV{devpath}="$attr{busnum}/$attr{devnum}"
RUN+="/sbin/fxload -I /lib/firmware/foo.hex -D /dev/bus/usb/$env{devpath}"
Only that $devpath evaluates to 1/8 or 10/7, but the number must always be 3 digits with zeros filling the leading digits, e.g.
/dev/bus/usb/001/008 or /dev/bus/usb/010/007
I have no idea how to do this in the rules files without calling an external script.
Regards,
Jasem
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: Loading firmware
2008-10-13 22:17 Loading firmware Jasem Mutlaq
2008-10-14 0:18 ` Dan Nicholson
2008-10-14 13:16 ` Jasem Mutlaq
@ 2008-10-14 14:33 ` Kay Sievers
2008-10-14 17:24 ` Jasem Mutlaq
` (7 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: Kay Sievers @ 2008-10-14 14:33 UTC (permalink / raw)
To: linux-hotplug
On Tue, Oct 14, 2008 at 12:17 AM, Jasem Mutlaq <mutlaqja@ikarustech.com> wrote:
> I need to load firmware to a USB camera via fxload. The problem is that
> fxload requires a path such as /dev/bus/usb/001/002 in order to load the
> firmware. So I wrote a udev rules file to do just that, however, the only
> useful variable I can obtain now is %k, and I get something in the form of
> usbdev1.2_ep00
That's not a USB _device_, it's a (not interesting) USB endpoint.
> which I then need to parse in some regexp magic in order to
> extract the bus and dev num in order to construct the full path. I used to
> be able to pull devnum and busnum ($env{BUSNUM}) but not anymore (using
> openSUSE 11).
That still works.
> Now I have a loader script that parses %k and constructs the
> path. But this is only a hack and not a real solution, is there a way to get
> the full path so I can pass it to fxload without resorting to these
> desperate measures? Appreciate your help.
Why not just use $DEVNAME?
RUN+="/sbin/fxload <firmware file option> -D $env{DEVNAME}"
Kay
^ permalink raw reply [flat|nested] 12+ messages in thread* RE: Loading firmware
2008-10-13 22:17 Loading firmware Jasem Mutlaq
` (2 preceding siblings ...)
2008-10-14 14:33 ` Kay Sievers
@ 2008-10-14 17:24 ` Jasem Mutlaq
2008-10-14 17:46 ` Kay Sievers
` (6 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: Jasem Mutlaq @ 2008-10-14 17:24 UTC (permalink / raw)
To: linux-hotplug
> That's not a USB _device_, it's a (not interesting) USB endpoint.
>
> > which I then need to parse in some regexp magic in order to
> > extract the bus and dev num in order to construct the full path. I
> used to
> > be able to pull devnum and busnum ($env{BUSNUM}) but not anymore
> (using
> > openSUSE 11).
>
> That still works.
I tried it on OpenSUSE 11 and it doesn't, $env{BUSNUM} and $env{DEVNUM} are empty strings, $env{DEVNAME} returns the USB endpoint which I can't pass to fxload.
> Why not just use $DEVNAME?
> RUN+="/sbin/fxload <firmware file option> -D $env{DEVNAME}"
This is what I get:
run_program: '/sbin/fxload' (stderr) '/dev/usbdev1.24_ep82: No such device or address'
run_program: '/sbin/fxload' returned with status 255
Thus far, fxload only works if it is passed something in the form of /dev/bus/usb/XXX/YYY
Cheers,
Jasem
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: Loading firmware
2008-10-13 22:17 Loading firmware Jasem Mutlaq
` (3 preceding siblings ...)
2008-10-14 17:24 ` Jasem Mutlaq
@ 2008-10-14 17:46 ` Kay Sievers
2008-10-14 18:08 ` Dan Nicholson
` (5 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: Kay Sievers @ 2008-10-14 17:46 UTC (permalink / raw)
To: linux-hotplug
On Tue, Oct 14, 2008 at 7:24 PM, Jasem Mutlaq <mutlaqja@ikarustech.com> wrote:
>> That's not a USB _device_, it's a (not interesting) USB endpoint.
>>
>> > which I then need to parse in some regexp magic in order to
>> > extract the bus and dev num in order to construct the full path. I
>> used to
>> > be able to pull devnum and busnum ($env{BUSNUM}) but not anymore
>> (using
>> > openSUSE 11).
>>
>> That still works.
>
> I tried it on OpenSUSE 11 and it doesn't, $env{BUSNUM} and $env{DEVNUM} are empty strings, $env{DEVNAME} returns the USB endpoint which I can't pass to fxload.
Sure you can't. As said, you need a device, not an endpoint, these
values _do_ exist at the device event.
>> Why not just use $DEVNAME?
>> RUN+="/sbin/fxload <firmware file option> -D $env{DEVNAME}"
>
> This is what I get:
>
> run_program: '/sbin/fxload' (stderr) '/dev/usbdev1.24_ep82: No such device or address'
> run_program: '/sbin/fxload' returned with status 255
That's expected behavior for endpoints.
> Thus far, fxload only works if it is passed something in the form of /dev/bus/usb/XXX/YYY
It should work with any usb device device node, forget the endpoints,
match on a usb device. You look at the wrong events, you get a bunch
of them on plugin, only one of them will be the one that works with
fxload, and definitely not the one with the *_ep*. The right one
should have: DEVTYPE=usb_device set.
Kay
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: Loading firmware
2008-10-13 22:17 Loading firmware Jasem Mutlaq
` (4 preceding siblings ...)
2008-10-14 17:46 ` Kay Sievers
@ 2008-10-14 18:08 ` Dan Nicholson
2008-10-15 12:05 ` Jasem Mutlaq
` (4 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: Dan Nicholson @ 2008-10-14 18:08 UTC (permalink / raw)
To: linux-hotplug
On Tue, Oct 14, 2008 at 10:46 AM, Kay Sievers <kay.sievers@vrfy.org> wrote:
> On Tue, Oct 14, 2008 at 7:24 PM, Jasem Mutlaq <mutlaqja@ikarustech.com> wrote:
>
>> Thus far, fxload only works if it is passed something in the form of /dev/bus/usb/XXX/YYY
>
> It should work with any usb device device node, forget the endpoints,
> match on a usb device. You look at the wrong events, you get a bunch
> of them on plugin, only one of them will be the one that works with
> fxload, and definitely not the one with the *_ep*. The right one
> should have: DEVTYPE=usb_device set.
For reference, look at the rule that actually creates the /dev/bus/usb links:
SUBSYSTEM="usb", ACTION="add", ENV{DEVTYPE}="usb_device",
NAME="bus/usb/$env{BUSNUM}/$env{DEVNUM}", MODE="0644"
To get some information about what's going on:
path=`udevadm info --query=path --name=/dev/bus/usb/$your/$node`
udevadm test $path
udevadm info --attribute-walk --path=$path
I suspect you'll end up with something like this (make sure it runs
somewhere after the above rule that sets the name):
SUBSYSTEM="usb", ACTION="add", ENV{DEVTYPE}="usb_device",
ATTR{idVendor}="xxxx", ATTR{idProduct}="yyyy", RUN+="/sbin/fxload -I
/lib/firmware/foo.hex -D $env{DEVNAME}"
--
Dan
^ permalink raw reply [flat|nested] 12+ messages in thread* RE: Loading firmware
2008-10-13 22:17 Loading firmware Jasem Mutlaq
` (5 preceding siblings ...)
2008-10-14 18:08 ` Dan Nicholson
@ 2008-10-15 12:05 ` Jasem Mutlaq
2008-10-15 12:32 ` Kay Sievers
` (3 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: Jasem Mutlaq @ 2008-10-15 12:05 UTC (permalink / raw)
To: linux-hotplug
> SUBSYSTEM="usb", ACTION="add", ENV{DEVTYPE}="usb_device",
> NAME="bus/usb/$env{BUSNUM}/$env{DEVNUM}", MODE="0644"
Yes, this is exactly what I have in 50-udev-default.rules.
> I suspect you'll end up with something like this (make sure it runs
> somewhere after the above rule that sets the name):
>
> SUBSYSTEM="usb", ACTION="add", ENV{DEVTYPE}="usb_device",
> ATTR{idVendor}="xxxx", ATTR{idProduct}="yyyy", RUN+="/sbin/fxload -I
> /lib/firmware/foo.hex -D $env{DEVNAME}"
I tried that, and now the rule wouldn't even apply. It seems that DEVTYPE="usb_device" is not handled correctly. If I remove this condition, the rule is applied. I have one file 99-sbig.rules which has the following:
SUBSYSTEM="usb", ACTION="add", SYSFS{idVendor}="0d97", SYSFS{idProduct}="0001", ENV{DEVTYPE}="usb_device", \
RUN+="/sbin/fxload -I /lib/firmware/sbigucam.hex -D $env{DEVNAME}"
I don't understand why DEVTYPE is not caught, I ran udev monitor and got the following when I plugged my USB cam:
---------------------------------
EVENT[1224070564.432382] add /devices/pci0000:00/0000:00:07.2/usb1/1-1 (usb)
ACTIONd
DEVPATH=/devices/pci0000:00/0000:00:07.2/usb1/1-1
SUBSYSTEM=usb
MAJOR\x189
MINOR$
DEVTYPE=usb_device
DEVICE=/proc/bus/usb/001/025
PRODUCTÙ7/1/1
TYPE%5/255/255
BUSNUM\01
DEVNUM\x025
SEQNUM\x1460
UEVENT[1224070564.434702] add /devices/pci0000:00/0000:00:07.2/usb1/1-1/usb_endpoint/usbdev1.25_ep00 (usb_endpoint)
ACTIONd
DEVPATH=/devices/pci0000:00/0000:00:07.2/usb1/1-1/usb_endpoint/usbdev1.25_ep00
SUBSYSTEM=usb_endpoint
MAJOR%3
MINOR=4
SEQNUM\x1461
UEVENT[1224070564.435629] add /devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0 (usb)
ACTIONd
DEVPATH=/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0
SUBSYSTEM=usb
DEVTYPE=usb_interface
DEVICE=/proc/bus/usb/001/025
PRODUCTÙ7/1/1
TYPE%5/255/255
INTERFACE%5/255/255
MODALIAS=usb:v0D97p0001d0001dcFFdscFFdpFFicFFiscFFipFF
SEQNUM\x1462
UDEV [1224070564.443609] add /devices/pci0000:00/0000:00:07.2/usb1/1-1/usb_endpoint/usbdev1.25_ep00 (
UDEV_LOG=7
ACTIONd
DEVPATH=/devices/pci0000:00/0000:00:07.2/usb1/1-1/usb_endpoint/usbdev1.25_ep00
SUBSYSTEM=usb_endpoint
MAJOR%3
MINOR=4
SEQNUM\x1461
UDEVD_EVENT=1
DEVNAME=/dev/usbdev1.25_ep00
UDEV [1224070564.462839] add /devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0 (usb)
UDEV_LOG=7
ACTIONd
DEVPATH=/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1:1.0
SUBSYSTEM=usb
DEVTYPE=usb_interface
DEVICE=/proc/bus/usb/001/025
PRODUCTÙ7/1/1
TYPE%5/255/255
INTERFACE%5/255/255
MODALIAS=usb:v0D97p0001d0001dcFFdscFFdpFFicFFiscFFipFF
SEQNUM\x1462
UDEVD_EVENT=1
---------------------------------------------------------------------
If I remove the ENV{DEVTYPE}="usb_device" from the rule, I can use $env{DEVICE} since it's the closest thing to what I need, albeit it's under /proc and that doesn't work, I need /dev/bus/usb/XXX/YYY. Of course, DEVNAME evaluates to /dev/usbdev1.25_ep00 which is useless.
At any rate, here is what I get in /var/log/messages
----------------------------------------------------------------------
Oct 15 14:36:04 linux-j3lx kernel: usb 1-1: new full speed USB device using uhci_hcd and address 25
Oct 15 14:36:04 linux-j3lx kernel: usb 1-1: configuration #1 chosen from 1 choice
Oct 15 14:36:04 linux-j3lx kernel: usb 1-1: New USB device found, idVendor
97, idProduct\001
Oct 15 14:36:04 linux-j3lx kernel: usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
Oct 15 14:36:04 linux-j3lx udevd[552]: msg_queue_insert: seq 1460 queued, 'add' 'usb'
Oct 15 14:36:04 linux-j3lx udevd[552]: udev_event_run: seq 1460 forked, pid [4658], 'add' 'usb', 0 seconds old
Oct 15 14:36:04 linux-j3lx udevd[552]: msg_queue_insert: seq 1461 queued, 'add' 'usb_endpoint'
Oct 15 14:36:04 linux-j3lx udevd[552]: msg_queue_insert: seq 1462 queued, 'add' 'usb'
Oct 15 14:36:04 linux-j3lx udevd-event[4658]: udev_rules_get_name: rule applied, '1-1' becomes 'bus/usb/001/025'
Oct 15 14:36:04 linux-j3lx udevd-event[4658]: udev_db_get_device: no db file to read /dev/.udev/db/\x2fdevices\x2fpci0000:00\x2f0000:00:07.2\x2fusb1\x2f1-1: No such file or directory
Oct 15 14:36:04 linux-j3lx udevd-event[4658]: udev_node_add: creating device node '/dev/bus/usb/001/025', major\x189, minor$, mode\x0660, uid=0, gid=0
Oct 15 14:36:04 linux-j3lx udevd-event[4658]: udev_node_mknod: atomically replace '/dev/bus/usb/001/025'
Oct 15 14:36:04 linux-j3lx udevd-event[4658]: udev_node_mknod: mknod(/dev/bus/usb/001/025.udev-tmp, 020660, 189, 24) failed: Operation not permitted
Oct 15 14:36:04 linux-j3lx udevd-event[4658]: udev_event_run: seq 1460 finished with -1
Oct 15 14:36:04 linux-j3lx udevd[552]: udev_done: seq 1460, pid [4658] exit with 1, 0 seconds old
Oct 15 14:36:04 linux-j3lx udevd[552]: udev_event_run: seq 1461 forked, pid [4659], 'add' 'usb_endpoint', 0 seconds old
Oct 15 14:36:04 linux-j3lx udevd-event[4659]: udev_rules_get_name: no node name set, will use kernel name 'usbdev1.25_ep00'
Oct 15 14:36:04 linux-j3lx udevd-event[4659]: udev_db_get_device: no db file to read /dev/.udev/db/\x2fdevices\x2fpci0000:00\x2f0000:00:07.2\x2fusb1\x2f1-1\x2fusb_endpoint\x2fusbdev1.25_ep00: No such file or directory
Oct 15 14:36:04 linux-j3lx udevd-event[4659]: udev_node_add: creating device node '/dev/usbdev1.25_ep00', major%3, minor=4, mode\x0660, uid=0, gid=0
Oct 15 14:36:04 linux-j3lx udevd-event[4659]: name_index: creating index: '/dev/.udev/names/usbdev1.25_ep00/\x2fdevices\x2fpci0000:00\x2f0000:00:07..2\x2fusb1\x2f1-1\x2fusb_endpoint\x2fusbdev1.25_ep00'
Oct 15 14:36:04 linux-j3lx udevd-event[4660]: run_program: '/sbin/modprobe usb:v0D97p0001d0001dcFFdscFFdpFFicFFiscFFipFF'
Oct 15 14:36:04 linux-j3lx udevd-event[4659]: pass_env_to_socket: passed 272 bytes to socket '/org/freedesktop/hal/udev_event',
Oct 15 14:36:04 linux-j3lx udevd-event[4659]: pass_env_to_socket: passed 272 bytes to socket '@/org/kernel/udev/monitor',
Oct 15 14:36:04 linux-j3lx udevd-event[4659]: udev_event_run: seq 1461 finished with 0
Oct 15 14:36:04 linux-j3lx udevd[552]: udev_event_run: seq 1462 forked, pid [4660], 'add' 'usb', 0 seconds old
Oct 15 14:36:04 linux-j3lx udevd[552]: udev_done: seq 1461, pid [4659] exit with 0, 0 seconds old
Oct 15 14:36:04 linux-j3lx udevd-event[4660]: run_program: '/sbin/modprobe' (stderr) 'FATAL: Module usb:v0D97p0001d0001dcFFdscFFdpFFicFFiscFFipFF not found.'
Oct 15 14:36:04 linux-j3lx udevd-event[4660]: run_program: '/sbin/modprobe' returned with status 1
Oct 15 14:36:04 linux-j3lx udevd-event[4660]: pass_env_to_socket: passed 335 bytes to socket '/org/freedesktop/hal/udev_event',
Oct 15 14:36:04 linux-j3lx udevd-event[4660]: pass_env_to_socket: passed 335 bytes to socket '@/org/kernel/udev/monitor',
Oct 15 14:36:04 linux-j3lx udevd-event[4660]: udev_event_run: seq 1462 finished with 0
Oct 15 14:36:04 linux-j3lx udevd[552]: udev_done: seq 1462, pid [4660] exit with 0, 0 seconds old
---------------------------------------------------------------------------------------------------------
Notice that despite the default rule in 50-udev-default.rules (NAME="bus/usb/$env{BUSNUM}/$env{DEVNUM}"), the log says:
udev_rules_get_name: no node name set, will use kernel name 'usbdev1.25_ep00'
Btw, I get the same results in Fedora 9 and openSUSE 11, so it doesn't appear to be distro-specific.
Any insights appreciated!
Cheers,
Jasem
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: Loading firmware
2008-10-13 22:17 Loading firmware Jasem Mutlaq
` (6 preceding siblings ...)
2008-10-15 12:05 ` Jasem Mutlaq
@ 2008-10-15 12:32 ` Kay Sievers
2008-10-15 12:44 ` Jasem Mutlaq
` (2 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: Kay Sievers @ 2008-10-15 12:32 UTC (permalink / raw)
To: linux-hotplug
On Wed, Oct 15, 2008 at 2:05 PM, Jasem Mutlaq <mutlaqja@ikarustech.com> wrote:
>> SUBSYSTEM="usb", ACTION="add", ENV{DEVTYPE}="usb_device",
>> NAME="bus/usb/$env{BUSNUM}/$env{DEVNUM}", MODE="0644"
>
> Yes, this is exactly what I have in 50-udev-default.rules.
>
>> I suspect you'll end up with something like this (make sure it runs
>> somewhere after the above rule that sets the name):
>>
>> SUBSYSTEM="usb", ACTION="add", ENV{DEVTYPE}="usb_device",
>> ATTR{idVendor}="xxxx", ATTR{idProduct}="yyyy", RUN+="/sbin/fxload -I
>> /lib/firmware/foo.hex -D $env{DEVNAME}"
>
> I tried that, and now the rule wouldn't even apply. It seems that DEVTYPE="usb_device" is not handled correctly. If I remove this condition, the rule is applied. I have one file 99-sbig.rules which has the following:
>
> SUBSYSTEM="usb", ACTION="add", SYSFS{idVendor}="0d97", SYSFS{idProduct}="0001", ENV{DEVTYPE}="usb_device", \
> RUN+="/sbin/fxload -I /lib/firmware/sbigucam.hex -D $env{DEVNAME}"
>
> I don't understand why DEVTYPE is not caught, I ran udev monitor and got the following when I plugged my USB cam:
>
> ---------------------------------
> EVENT[1224070564.432382] add /devices/pci0000:00/0000:00:07.2/usb1/1-1 (usb)
That reads "UDEV [...] ..." since a long time, what old version of
udev you are running? It does not look like Fedora9 or openSUSE11.
Such old udev versions might not work with device nodes created by a
kernel bus-device.
Kay
^ permalink raw reply [flat|nested] 12+ messages in thread* RE: Loading firmware
2008-10-13 22:17 Loading firmware Jasem Mutlaq
` (7 preceding siblings ...)
2008-10-15 12:32 ` Kay Sievers
@ 2008-10-15 12:44 ` Jasem Mutlaq
2008-10-15 13:22 ` Kay Sievers
2008-10-15 13:59 ` Jasem Mutlaq
10 siblings, 0 replies; 12+ messages in thread
From: Jasem Mutlaq @ 2008-10-15 12:44 UTC (permalink / raw)
To: linux-hotplug
> That reads "UDEV [...] ..." since a long time, what old version of
> udev you are running? It does not look like Fedora9 or openSUSE11.
> Such old udev versions might not work with device nodes created by a
> kernel bus-device.
linux-j3lx:/etc/udev/rules.d # uname -a
Linux linux-j3lx 2.6.25.5-1.1-default #1 SMP 2008-06-07 01:55:22 +0200 i686 i686 i386 GNU/Linux
linux-j3lx:/etc/udev/rules.d # udevd --version
120
linux-j3lx:/etc/udev/rules.d # rpm -qa udev
udev-120-13.1
linux-j3lx:/etc/udev/rules.d # cat /etc/SuSE-release
openSUSE 11.0 (i586)
VERSION = 11.0
Any more suggestions?
Cheers,
Jasem
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: Loading firmware
2008-10-13 22:17 Loading firmware Jasem Mutlaq
` (8 preceding siblings ...)
2008-10-15 12:44 ` Jasem Mutlaq
@ 2008-10-15 13:22 ` Kay Sievers
2008-10-15 13:59 ` Jasem Mutlaq
10 siblings, 0 replies; 12+ messages in thread
From: Kay Sievers @ 2008-10-15 13:22 UTC (permalink / raw)
To: linux-hotplug
On Wed, Oct 15, 2008 at 2:44 PM, Jasem Mutlaq <mutlaqja@ikarustech.com> wrote:
>> That reads "UDEV [...] ..." since a long time, what old version of
>> udev you are running? It does not look like Fedora9 or openSUSE11.
>> Such old udev versions might not work with device nodes created by a
>> kernel bus-device.
>
> linux-j3lx:/etc/udev/rules.d # uname -a
> Linux linux-j3lx 2.6.25.5-1.1-default #1 SMP 2008-06-07 01:55:22 +0200 i686 i686 i386 GNU/Linux
>
> linux-j3lx:/etc/udev/rules.d # udevd --version
> 120
>
> linux-j3lx:/etc/udev/rules.d # rpm -qa udev
> udev-120-13.1
>
> linux-j3lx:/etc/udev/rules.d # cat /etc/SuSE-release
> openSUSE 11.0 (i586)
> VERSION = 11.0
>
> Any more suggestions?
I have no idea what's going wrong your box, but unless you find an
explanation for the following, I guess we can't really help from
remote.
On openSUSE 11 there is no output like you have, it's from a pretty
old version of udevmonitor
EVENT[1224070564.432382] add
/devices/pci0000:00/0000:00:07.2/usb1/1-1 (usb)
On openSUSE 11 it always reads:
UDEV [1224076272.737777] add
/devices/pci0000:00/0000:00:1d.3/usb4/4-2 (usb)
And the usb device events looks like this, and always contain DEVNAME:
UDEV [1224076312.193348] add
/devices/pci0000:00/0000:00:1d.3/usb4/4-2 (usb)
UDEV_LOG=3
ACTIONd
DEVPATH=/devices/pci0000:00/0000:00:1d.3/usb4/4-2
SUBSYSTEM=usb
MAJOR\x189
MINOR87
DEVTYPE=usb_device
DRIVER=usb
PRODUCTH3/2016/1
TYPE=0/0/0
BUSNUM\04
DEVNUM\04
SEQNUM\x1364
UDEVD_EVENT=1
DEVNAME=/dev/bus/usb/004/004
You could do:
killall udevd
/sbin/udevd --debug
and plug in your camera, and see if that tells something.
Here is says:
[15889] udev_rules_get_name: rule applied, '4-2' becomes 'bus/usb/004/004'
Kay
^ permalink raw reply [flat|nested] 12+ messages in thread* RE: Loading firmware
2008-10-13 22:17 Loading firmware Jasem Mutlaq
` (9 preceding siblings ...)
2008-10-15 13:22 ` Kay Sievers
@ 2008-10-15 13:59 ` Jasem Mutlaq
10 siblings, 0 replies; 12+ messages in thread
From: Jasem Mutlaq @ 2008-10-15 13:59 UTC (permalink / raw)
To: linux-hotplug
> I have no idea what's going wrong your box, but unless you find an
> explanation for the following, I guess we can't really help from
> remote.
>
> On openSUSE 11 there is no output like you have, it's from a pretty
> old version of udevmonitor
> EVENT[1224070564.432382] add
> /devices/pci0000:00/0000:00:07.2/usb1/1-1 (usb)
>
> On openSUSE 11 it always reads:
> UDEV [1224076272.737777] add
> /devices/pci0000:00/0000:00:1d.3/usb4/4-2 (usb)
The problem has been resolved. I was running a few instances of major distributions (openSUSE, Fedora, Ubuntu..etc) under VMWare to insure that the camera installs and works correctly under all. So it seems that udev behaves differently under VMware? I'm not sure. But when I applied the rule in my laptop which runs a vanilla openSUSE 11, everything worked as expected. I was relying on virtualization to make my testing easier, and it backfired :-)
At any rate, thank you for the help and support!
Cheers,
Jasem
^ permalink raw reply [flat|nested] 12+ messages in thread