* Re: USB driver and udev_run_devd
2007-05-10 20:03 USB driver and udev_run_devd Greg Huber
@ 2007-05-10 20:45 ` Kay Sievers
2007-05-11 12:59 ` Greg Huber
` (4 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: Kay Sievers @ 2007-05-10 20:45 UTC (permalink / raw)
To: linux-hotplug
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
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: USB driver and udev_run_devd
2007-05-10 20:03 USB driver and udev_run_devd Greg Huber
2007-05-10 20:45 ` Kay Sievers
@ 2007-05-11 12:59 ` Greg Huber
2007-05-11 14:53 ` Kay Sievers
` (3 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: Greg Huber @ 2007-05-11 12:59 UTC (permalink / raw)
To: linux-hotplug
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
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
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: USB driver and udev_run_devd
2007-05-10 20:03 USB driver and udev_run_devd Greg Huber
2007-05-10 20:45 ` Kay Sievers
2007-05-11 12:59 ` Greg Huber
@ 2007-05-11 14:53 ` Kay Sievers
2007-05-11 15:30 ` Greg Huber
` (2 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: Kay Sievers @ 2007-05-11 14:53 UTC (permalink / raw)
To: linux-hotplug
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
> 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
> 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
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: USB driver and udev_run_devd
2007-05-10 20:03 USB driver and udev_run_devd Greg Huber
` (2 preceding siblings ...)
2007-05-11 14:53 ` Kay Sievers
@ 2007-05-11 15:30 ` Greg Huber
2007-05-11 19:55 ` Kay Sievers
2007-05-11 20:42 ` Greg Huber
5 siblings, 0 replies; 7+ messages in thread
From: Greg Huber @ 2007-05-11 15:30 UTC (permalink / raw)
To: linux-hotplug
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
>> 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
>
>> 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
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: USB driver and udev_run_devd
2007-05-10 20:03 USB driver and udev_run_devd Greg Huber
` (3 preceding siblings ...)
2007-05-11 15:30 ` Greg Huber
@ 2007-05-11 19:55 ` Kay Sievers
2007-05-11 20:42 ` Greg Huber
5 siblings, 0 replies; 7+ messages in thread
From: Kay Sievers @ 2007-05-11 19:55 UTC (permalink / raw)
To: linux-hotplug
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
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: USB driver and udev_run_devd
2007-05-10 20:03 USB driver and udev_run_devd Greg Huber
` (4 preceding siblings ...)
2007-05-11 19:55 ` Kay Sievers
@ 2007-05-11 20:42 ` Greg Huber
5 siblings, 0 replies; 7+ messages in thread
From: Greg Huber @ 2007-05-11 20:42 UTC (permalink / raw)
To: linux-hotplug
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
^ permalink raw reply [flat|nested] 7+ messages in thread