USB driver and udev_run_devd

USB driver and udev_run_devd

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

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
SEQNUM\x1220

UEVENT[1178825388.168538] remove@/module/dlpd/drivers
ACTION=remove
DEVPATH=/module/dlpd/drivers
SUBSYSTEM=module
SEQNUM\x1221

UEVENT[1178825388.169668] remove@/module/dlpd
ACTION=remove
DEVPATH=/module/dlpd
SUBSYSTEM=module
SEQNUM\x1222

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
SEQNUM\x1216
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
SEQNUM\x1217
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
SEQNUM\x1215
UDEVD_EVENT=1

UDEV  [1178825388.199113] add@/class/usb_endpoint/usbdev4.6_ep81
UDEV_LOG=3
ACTION­d
DEVPATH=/class/usb_endpoint/usbdev4.6_ep81
SUBSYSTEM=usb_endpoint
SEQNUM\x1218
MAJOR%3
MINOR%
UDEVD_EVENT=1
DEVNAME=/dev/usbdev4.6_ep81

UDEV  [1178825388.253372] add@/class/usb_endpoint/usbdev4.6_ep02
UDEV_LOG=3
ACTION­d
DEVPATH=/class/usb_endpoint/usbdev4.6_ep02
SUBSYSTEM=usb_endpoint
SEQNUM\x1219
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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: USB driver and udev_run_devd

[Kay Sievers]

On 5/10/07, Greg Huber <ghuber@vanteon.com> wrote:
> 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.

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

-------------------------------------------------------------------------
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: USB driver and udev_run_devd

[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
ACTION­d
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

Kay Sievers wrote:
> On 5/10/07, Greg Huber <ghuber@vanteon.com> wrote:
>> 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.
>
> 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
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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: USB driver and udev_run_devd

[Kay Sievers]

On 5/11/07, Greg Huber <ghuber@vanteon.com> wrote:
>
> /proc/$(pidof udev_run_devd)/environ returned (formatted)
>
> [root@huberkahn 6282]# cat environ
> UDEV_LOG=3
> ACTION­d
> 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

> Kay Sievers wrote:
> > On 5/10/07, Greg Huber <ghuber@vanteon.com> wrote:
> >> 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.
> >
> > 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

-------------------------------------------------------------------------
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: USB driver and udev_run_devd

[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




Kay Sievers wrote:
> On 5/11/07, Greg Huber <ghuber@vanteon.com> wrote:
>>
>> /proc/$(pidof udev_run_devd)/environ returned (formatted)
>>
>> [root@huberkahn 6282]# cat environ
>> UDEV_LOG=3
>> ACTION­d
>> 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
>
>> Kay Sievers wrote:
>> > On 5/10/07, Greg Huber <ghuber@vanteon.com> wrote:
>> >> 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.
>> >
>> > 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
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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: USB driver and udev_run_devd

[Kay Sievers]

On 5/11/07, Greg Huber <ghuber@vanteon.com> wrote:
> /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?

> 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

-------------------------------------------------------------------------
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: USB driver and udev_run_devd

[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




Kay Sievers wrote:
> On 5/11/07, Greg Huber <ghuber@vanteon.com> wrote:
>> /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?
>
>> 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
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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel