Debugging udev

Debugging udev

[Gary Thomas]

I'm having trouble with udev creating all the devices I need in
my system.  Based on the latest master, using udev 164.

My system is based on the 3.0 kernel (mainline, not yocto) with
Video4Linux enabled with OMAP3 ISP.  This creates a bunch of
special devices:
   # ls /sys/class/video4linux/
   v4l-subdev0  v4l-subdev3  v4l-subdev6  video0       video3       video6
   v4l-subdev1  v4l-subdev4  v4l-subdev7  video1       video4
   v4l-subdev2  v4l-subdev5  v4l-subdev8  video2       video5
However, udev is not actually creating the device nodes.

Any ideas why?
Any hints on how to debug this?

Thanks

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: Debugging udev

[Robert Berger]

Hi Gary,

I'm currently on the road and can not try it myself on a yocto/poky, so
here are some wild guesses and ideas...

On 08/30/2011 08:38 PM, Gary Thomas wrote:
> I'm having trouble with udev creating all the devices I need in
> my system.  Based on the latest master, using udev 164.
> 
> My system is based on the 3.0 kernel (mainline, not yocto) with
> Video4Linux enabled with OMAP3 ISP.  This creates a bunch of
> special devices:
>   # ls /sys/class/video4linux/
>   v4l-subdev0  v4l-subdev3  v4l-subdev6  video0       video3       video6
>   v4l-subdev1  v4l-subdev4  v4l-subdev7  video1       video4
>   v4l-subdev2  v4l-subdev5  v4l-subdev8  video2       video5
> However, udev is not actually creating the device nodes.
> 
> Any ideas why?
> Any hints on how to debug this?

*) make sure udev is running - I guess it is.
*) run on a terminal something like udevmonitor --env or udevadm monitor
(don't know which one comes with poky) and load some kernel modules
where udev works. Like this you should be able to see the messages sent
by the kernel to udev. Manually load v4l so you can see if the kernel
events are sent.
*) if messages are sent, you most likely need to cook the udev config to
create the proper devices for you
*) Manually you could do make the /dev entries like this:

If you run

find /sys -name dev

you will get many hits, such as:

/sys/block/fd0/dev

cat /sys/block/fd0/dev
2:0

means if loading this module, one should also create its device as follows:
mknod /dev/fd0 b 2 0

Your goal should be to make a 'dev' entry appear under /sys for your
device and then udev (and mdev in embedded busybox systems) will mknod
it automatically.

*) DEVTMPFS
Besides I'm not a big fan of udev/mkdev for embedded systems since we
have user space dependencies. The kernel obviously knows about the v4l
class, but there are no device entries made.

I prefer to use DEVTMPFS (enable CONFIG_DEVTMPFS in your kernel config)
where the kernel makes the dev entries and you don't have user space
dependencies.

> 
> Thanks
> 

I hope this gives you some new ideas;)

Regards,

Robert


..."Experience is what causes a person to make new mistakes instead of
old ones."

My public pgp key is available at:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x90320BF1

Re: Debugging udev

[Koen Kooi]

Op 3 sep. 2011, om 12:20 heeft Robert Berger het volgende geschreven:
> 
> *) DEVTMPFS
> Besides I'm not a big fan of udev/mkdev for embedded systems since we
> have user space dependencies. The kernel obviously knows about the v4l
> class, but there are no device entries made.
> 
> I prefer to use DEVTMPFS (enable CONFIG_DEVTMPFS in your kernel config)
> where the kernel makes the dev entries and you don't have user space
> dependencies.

That's actually mandatory for recent versions of udev (164 is quite old already). Recent udevs only take care of the policy stuff, devnodes are handled by the kernel.

Re: Debugging udev

[Robert Berger]

Hi Koen,

On 09/03/2011 08:02 PM, Koen Kooi wrote:
> 
> Op 3 sep. 2011, om 12:20 heeft Robert Berger het volgende geschreven:
>>
>> *) DEVTMPFS

...

> 
> That's actually mandatory for recent versions of udev (164 is quite old already). Recent udevs only take care of the policy stuff, devnodes are handled by the kernel.

Thanks for pointing this out, I was not aware of it.
Do you have any idea if mdev from busybox is going to move also along
those lines providing only policy stuff and letting the kernel do the
devnodes? As an incentive mdev it could be even smaller.

Regards,

Robert


..."Nothing ever becomes real until it is experienced." - John Keats

My public pgp key is available at:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x90320BF1