USB driver and udev_run_devd

DISCUSSION Greg Huber 2 participants 7 messages May 10, 2007 – May 11, 2007

lore

Share & tools

lore

Greg Huber

author

2007-05-10 20:03 UTC #0 lore raw

I hope this is the correct place for this...

I am currently developing a driver for a USB dongle. My development system is based on FC6, fully up-to-date.

Everything seems to work fine until I unload the driver (actual device still plugged in). I end up with a "/lib/udev/udev_run_devd" process running rouge and consuming mass amounts of CPU time. After tracing udev events I'm speculating that there is a problem when the system re-adds the device end-points back into the system. (trace below)

The 51-hotplug.rules handles (by ignoring) SUBSYSTEM types of 'module' and 'drivers' but not 'usb_endpoint'. I'm guessing that when the rules in the hotplug container get checked, the event with SUBSYSTEM=usb_endpoint causes udev_run_devd to execute but there is something missing or incorrectly configured causing it to loop infintely.

Could anyone please tell me what is really happening and how I might prevent udev_run_devd from running (or at least get it to exit normally).

Thank You.

Greg

From strace of udev_run_devd

getdents64(3, /* 170 entries */, 4096)  = 4080
getdents64(3, /* 170 entries */, 4096)  = 4080
getdents64(3, /* 170 entries */, 4096)  = 4080
getdents64(3, /* 170 entries */, 4096)  = 4080

...

below is a trace from udevmonitor

UEVENT[1178825388.167826] remove@/bus/usb/drivers/DLP-D USB Security Dongle ACTION=remove
DEVPATH=/bus/usb/drivers/DLP-D USB Security Dongle SUBSYSTEM=drivers
SEQNUM20

UEVENT[1178825388.168538] remove@/module/dlpd/drivers ACTION=remove
DEVPATH=/module/dlpd/drivers
SUBSYSTEM=module
SEQNUM21

UEVENT[1178825388.169668] remove@/module/dlpd ACTION=remove
DEVPATH=/module/dlpd
SUBSYSTEM=module
SEQNUM22

UDEV [1178825388.174263] remove@/class/usb_endpoint/usbdev4.6_ep81 UDEV_LOG=3
ACTION=remove
DEVPATH=/class/usb_endpoint/usbdev4.6_ep81 SUBSYSTEM=usb_endpoint
SEQNUM16
MAJOR%3
MINOR%
UDEVD_EVENT=1
DEVNAME=/dev/usbdev4.6_ep81

UDEV [1178825388.186712] remove@/class/usb_endpoint/usbdev4.6_ep02 UDEV_LOG=3
ACTION=remove
DEVPATH=/class/usb_endpoint/usbdev4.6_ep02 SUBSYSTEM=usb_endpoint
SEQNUM17
MAJOR%3
MINOR&
UDEVD_EVENT=1
DEVNAME=/dev/usbdev4.6_ep02

UDEV [1178825388.193601] remove@/class/usb
UDEV_LOG=3
ACTION=remove
DEVPATH=/class/usb
SUBSYSTEM=class
SEQNUM15
UDEVD_EVENT=1

UDEV [1178825388.199113] add@/class/usb_endpoint/usbdev4.6_ep81 UDEV_LOG=3
ACTIONd
DEVPATH=/class/usb_endpoint/usbdev4.6_ep81 SUBSYSTEM=usb_endpoint
SEQNUM18
MAJOR%3
MINOR%
UDEVD_EVENT=1
DEVNAME=/dev/usbdev4.6_ep81

UDEV [1178825388.253372] add@/class/usb_endpoint/usbdev4.6_ep02 UDEV_LOG=3
ACTIONd
DEVPATH=/class/usb_endpoint/usbdev4.6_ep02 SUBSYSTEM=usb_endpoint
SEQNUM19
MAJOR%3
MINOR&
UDEVD_EVENT=1
DEVNAME=/dev/usbdev4.6_ep02

--
Greg Huber
Principal Engineer
Vanteon Corporation
255 Woodcliff Drive, Suite 200
Fairport, NY 14450
Office: (585) 419-9564
Fax: (585) 248-0537
www.vanteon.com <http://www.vanteon.com> - Embedded for Your Future

-------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Kay Sievers

2007-05-10 20:45 UTC #1 lore raw

Quoted 13 lines · Greg Huber

I hope this is the correct place for this...
I am currently developing a driver for a USB dongle. My development system is based on FC6, fully up-to-date.
Everything seems to work fine until I unload the driver (actual device still plugged in). I end up with a "/lib/udev/udev_run_devd" process running rouge and consuming mass amounts of CPU time. After tracing udev events I'm speculating that there is a problem when the system re-adds the device end-points back into the system. (trace below)

Quoted 6 lines

The 51-hotplug.rules handles (by ignoring) SUBSYSTEM types of 'module' and 'drivers' but not 'usb_endpoint'. I'm guessing that when the rules in the hotplug container get checked, the event with SUBSYSTEM=usb_endpoint causes udev_run_devd to execute but there is something missing or incorrectly configured causing it to loop infintely.

It sounds strange, no idea why the readdir() loop does not exit.

Could you please check which event it is by looking at:
/proc/$(pidof udev_run_devd)/environ

Thanks,
Kay

Greg Huber

author

2007-05-11 12:59 UTC #2 lore raw

In reply to Greg Huber

Kay,
Thank you for your reply.
(sorry for the delay, the last reboot required a filesystem check)

/proc/$(pidof udev_run_devd)/environ returned (formatted)

[root@huberkahn 6282]# cat environ
UDEV_LOG=3
ACTIONd
DEVPATH=/class/usb_endpoint/usbdev4.2_ep81
SUBSYSTEM=usb_endpoint
SEQNUM’0
MAJOR%3
MINOR!
UDEVD_EVENT=1
DEVNAME=/dev/usbdev4.2_ep81
[root@huberkahn 6282]#

Greg

Quoted 28 lines · Kay Sievers

Quoted 13 lines · Greg Huber
I hope this is the correct place for this...
I am currently developing a driver for a USB dongle. My development system is based on FC6, fully up-to-date.
Everything seems to work fine until I unload the driver (actual device still plugged in). I end up with a "/lib/udev/udev_run_devd" process running rouge and consuming mass amounts of CPU time. After tracing udev events I'm speculating that there is a problem when the system re-adds the device end-points back into the system. (trace below)
Quoted 6 lines
The 51-hotplug.rules handles (by ignoring) SUBSYSTEM types of 'module' and 'drivers' but not 'usb_endpoint'. I'm guessing that when the rules in the hotplug container get checked, the event with SUBSYSTEM=usb_endpoint causes udev_run_devd to execute but there is something missing or incorrectly configured causing it to loop infintely.
It sounds strange, no idea why the readdir() loop does not exit.
Could you please check which event it is by looking at:
/proc/$(pidof udev_run_devd)/environ
Thanks,
Kay

Signature · 19 lines

Greg Huber
Principal Engineer
Vanteon Corporation
255 Woodcliff Drive, Suite 200
Fairport, NY 14450
Office: (585) 419-9564
Fax: (585) 248-0537
www.vanteon.com <http://www.vanteon.com>  - Embedded for Your Future


-------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Kay Sievers

2007-05-11 14:53 UTC #3 lore raw

In reply to Greg Huber

Quoted 14 lines · Greg Huber

/proc/$(pidof udev_run_devd)/environ returned (formatted)
[root@huberkahn 6282]# cat environ
UDEV_LOG=3
ACTIONd
DEVPATH=/class/usb_endpoint/usbdev4.2_ep81
SUBSYSTEM=usb_endpoint
SEQNUM’0
MAJOR%3
MINOR!
UDEVD_EVENT=1
DEVNAME=/dev/usbdev4.2_ep81
[root@huberkahn 6282]#

Hmm, what does:
ls -l /proc/$(pidof udev_run_devd)/fd/
print?

I still have no idea why the readdir() ends in an endless loop. What kind of filesystem is /etc on?

Thanks,
Kay

Quoted 22 lines

Quoted 21 lines · Kay Sievers
Quoted 19 lines · Greg Huber
I hope this is the correct place for this...
I am currently developing a driver for a USB dongle. My development system is based on FC6, fully up-to-date.
Everything seems to work fine until I unload the driver (actual device still plugged in). I end up with a "/lib/udev/udev_run_devd" process running rouge and consuming mass amounts of CPU time. After tracing udev events I'm speculating that there is a problem when the system re-adds the device end-points back into the system. (trace below)
The 51-hotplug.rules handles (by ignoring) SUBSYSTEM types of 'module' and 'drivers' but not 'usb_endpoint'. I'm guessing that when the rules in the hotplug container get checked, the event with SUBSYSTEM=usb_endpoint causes udev_run_devd to execute but there is something missing or incorrectly configured causing it to loop infintely.

Quoted 4 lines

Quoted 4 lines
It sounds strange, no idea why the readdir() loop does not exit.
Could you please check which event it is by looking at:
/proc/$(pidof udev_run_devd)/environ

Greg Huber

author

2007-05-11 15:30 UTC #4 lore raw

In reply to Greg Huber

Kay,

/etc is a standard ext3 filesystem, included on root.

ls -l /proc/$(pidof udev_run_devd)/fd/ returns

[root@huberkahn ~]# ls -l /proc/3939/fd/
total 0
lrwx------ 1 root root 64 May 11 11:07 0 -> /dev/null lrwx------ 1 root root 64 May 11 11:07 1 -> /dev/null lrwx------ 1 root root 64 May 11 11:07 2 -> /dev/null lr-x------ 1 root root 64 May 11 11:07 3 -> /etc/dev.d/default [root@huberkahn ~]#

As a side note, I tried running the 111 release of udev, after removing the 095 version and patching rc.sysinit. This had a lot of problems but some might be explained by the inability to compile more then one object from the extras directory.

I'm not sure if it's worth getting this working given that Fedora 7 will be released is a few weeks (hopefully). The down side is that it includes udev version 106, which still has the 'run_directory' stuff in it.

Thanks again.

Greg Huber

Quoted 52 lines · Kay Sievers

Quoted 14 lines · Greg Huber
/proc/$(pidof udev_run_devd)/environ returned (formatted)
[root@huberkahn 6282]# cat environ
UDEV_LOG=3
ACTIONd
DEVPATH=/class/usb_endpoint/usbdev4.2_ep81
SUBSYSTEM=usb_endpoint
SEQNUM’0
MAJOR%3
MINOR!
UDEVD_EVENT=1
DEVNAME=/dev/usbdev4.2_ep81
[root@huberkahn 6282]#
Hmm, what does:
ls -l /proc/$(pidof udev_run_devd)/fd/
print?
I still have no idea why the readdir() ends in an endless loop. What kind of filesystem is /etc on?
Thanks,
Kay
Quoted 26 lines
Quoted 25 lines · Kay Sievers
Quoted 13 lines · Greg Huber
I hope this is the correct place for this...
I am currently developing a driver for a USB dongle. My development system is based on FC6, fully up-to-date.
Everything seems to work fine until I unload the driver (actual device still plugged in). I end up with a "/lib/udev/udev_run_devd" process running rouge and consuming mass amounts of CPU time. After tracing udev events I'm speculating that there is a problem when the system re-adds the device end-points back into the system. (trace below)
Quoted 6 lines
The 51-hotplug.rules handles (by ignoring) SUBSYSTEM types of 'module' and 'drivers' but not 'usb_endpoint'. I'm guessing that when the rules in the hotplug container get checked, the event with SUBSYSTEM=usb_endpoint causes udev_run_devd to execute but there is something missing or incorrectly configured causing it to loop infintely.
It sounds strange, no idea why the readdir() loop does not exit.
Could you please check which event it is by looking at:
/proc/$(pidof udev_run_devd)/environ

Signature · 19 lines

Greg Huber
Principal Engineer
Vanteon Corporation
255 Woodcliff Drive, Suite 200
Fairport, NY 14450
Office: (585) 419-9564
Fax: (585) 248-0537
www.vanteon.com <http://www.vanteon.com>  - Embedded for Your Future


-------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Kay Sievers

2007-05-11 19:55 UTC #5 lore raw

In reply to Greg Huber

Quoted 1 line · Greg Huber

/etc is a standard ext3 filesystem, included on root.

Hmm, that failure sounds really weird. The code didn't change for a very long time and nobody else ever reported a similar issue. Did you run an fsck in the rootfs recently?

What does a:
ls -la /etc/dev.d/default/
print.

and what does a:
find /etc/dev.d/default/
print?

Just to ckeck if we are on the right track, does renaming the /etc/dev.d/default/ directory to something else makes the failure to go away?

Quoted 4 lines

I'm not sure if it's worth getting this working given that Fedora 7 will be released is a few weeks (hopefully). The down side is that it includes udev version 106, which still has the 'run_directory' stuff in it.

Yeah, but it would still be nice to know what's going on here, because the code that spins, is the same code that reads the config files.

Kay

Greg Huber

author

2007-05-11 20:42 UTC #6 lore raw

In reply to Greg Huber

Kay,
Sorry, I lost the actual results when the system crashed again. But the /etc/dev.d/default/ directory exists and is empty.

Changing it's name allows udev_run_devd to complete but something, not visible with 'ps -elf' is running rogue, and eventually crashed the system.

Another data point is that if I remove the device before unloading the driver, everything cleans up nicely. I suspect that this is because there are no endpoints to re-attach. The spin is probably triggered by an 'add' event of subsystem type 'usb_endpoint' going through the hotplug rules.

I tried adding 'usb_endpoint' to the hotplug rules but ended up with 3 rogue pam processes instead of /udev_run_devd./

Thanks for taking the time to look into this

Greg

Quoted 28 lines · Kay Sievers

Quoted 1 line · Greg Huber
/etc is a standard ext3 filesystem, included on root.
Hmm, that failure sounds really weird. The code didn't change for a very long time and nobody else ever reported a similar issue. Did you run an fsck in the rootfs recently?
What does a:
ls -la /etc/dev.d/default/
print.
and what does a:
find /etc/dev.d/default/
print?
Just to ckeck if we are on the right track, does renaming the /etc/dev.d/default/ directory to something else makes the failure to go away?
Quoted 4 lines
I'm not sure if it's worth getting this working given that Fedora 7 will be released is a few weeks (hopefully). The down side is that it includes udev version 106, which still has the 'run_directory' stuff in it.
Yeah, but it would still be nice to know what's going on here, because the code that spins, is the same code that reads the config files.
Kay

Signature · 19 lines

Greg Huber
Principal Engineer
Vanteon Corporation
255 Woodcliff Drive, Suite 200
Fairport, NY 14450
Office: (585) 419-9564
Fax: (585) 248-0537
www.vanteon.com <http://www.vanteon.com>  - Embedded for Your Future


-------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel