[PATCH] queue usb hotplug events

[PATCH] queue usb hotplug events

[Olaf Hering]

Hi,

there is a hardcoded sleep 3 in the usb.agent. But this is wrong,
because the kernel runs all hotplug events at once for a new hub. The
result is that every event still runs in parallel, just 3 seconds later.

This patch implements an userland fifo.

touch an unique file
wait one second to let things settle
build a list with lockfiles, oldest last
grab the pid of the oldest agent
if this pid match the running agent, proceed
if all lockfiles are gone, proceed as well, provides a way to workaround
a hanging event
otherwise wait a second and try again


Index: etc/hotplug/usb.agent
=================================--- etc/hotplug/usb.agent	(revision 13)
+++ etc/hotplug/usb.agent	(working copy)
@@ -367,7 +367,15 @@
     # with slow HID devices and "usbmodules".
     # starting with 2.5, all hcds must queue control traffic.
     if [ "$DEVPATH" = "" ]; then
-	sleep 3
+	touch "${REMOVER}.queue.$$"
+    	until [ `sleep 1` ] ; do
+		lockfiles=`ls -t /var/run/usb/*.queue.* 2>/dev/null`
+		pid=${lockfiles##*.}
+		debug_mesg $pid $lockfiles
+		test "$pid" = "$$" && { debug_mesg pid $$ proceeds ; break; }
+		test "$lockfiles" = "" && { debug_mesg all lockfiles gone ; break; }
+		debug_mesg wait 1 second for pid $pid
+	done
     fi
 
     usb_convert_vars
@@ -426,6 +434,10 @@
         /sbin/devlabel restart
     fi
 
+    if [ -e "${REMOVER}.queue.$$" ]; then
+	debug_mesg pid $$ done
+	rm -f "${REMOVER}.queue.$$"
+    fi
     ;;
 
 remove)


-- 
USB is for mice, FireWire is for men!


-------------------------------------------------------
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
_______________________________________________
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: [PATCH] queue usb hotplug events

[David Brownell]

Olaf Hering wrote:
> Hi,
> 
> there is a hardcoded sleep 3 in the usb.agent. But this is wrong,
> because the kernel runs all hotplug events at once for a new hub. The
> result is that every event still runs in parallel, just 3 seconds later.

That "sleep" is a workaround for "uhci" and "usb-uhci" bugs:
they don't queue control transfers.  No complete user mode
workaround is possible; it doesn't affect just hotplug, or
even just usbfs-based applications.

The real fix is just to get rid of it on 2.5, where "uhci-hcd"
has been fixed, rather than to keep making all USB hotplugging
be annoyingly slow.

That's why I won't merge this patch.

- Dave




-------------------------------------------------------
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
_______________________________________________
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: [PATCH] queue usb hotplug events

[Olaf Hering]

 On Sat, Jun 07, David Brownell wrote:

> Olaf Hering wrote:
> >Hi,
> >
> >there is a hardcoded sleep 3 in the usb.agent. But this is wrong,
> >because the kernel runs all hotplug events at once for a new hub. The
> >result is that every event still runs in parallel, just 3 seconds later.
> 
> That "sleep" is a workaround for "uhci" and "usb-uhci" bugs:
> they don't queue control transfers.  No complete user mode
> workaround is possible; it doesn't affect just hotplug, or
> even just usbfs-based applications.

my patch fixes the timeouts. Have you even tried it?

-- 
USB is for mice, FireWire is for men!


-------------------------------------------------------
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
_______________________________________________
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: [PATCH] queue usb hotplug events

[David Brownell]

Olaf Hering wrote:

>>That "sleep" is a workaround for "uhci" and "usb-uhci" bugs:
>>they don't queue control transfers.  No complete user mode
>>workaround is possible; it doesn't affect just hotplug, or
>>even just usbfs-based applications.
> 
> 
> my patch fixes the timeouts. Have you even tried it?

Actually it's already fixed on 2.5, the check for $DEVPATH
will fail on earlier kernels.






-------------------------------------------------------
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
_______________________________________________
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: [PATCH] queue usb hotplug events

[Olaf Hering]

 On Sat, Jun 07, David Brownell wrote:

> Olaf Hering wrote:
> 
> >>That "sleep" is a workaround for "uhci" and "usb-uhci" bugs:
> >>they don't queue control transfers.  No complete user mode
> >>workaround is possible; it doesn't affect just hotplug, or
> >>even just usbfs-based applications.
> >
> >
> >my patch fixes the timeouts. Have you even tried it?
> 
> Actually it's already fixed on 2.5, the check for $DEVPATH
> will fail on earlier kernels.

Ok, DEVPATH does not exist in 2.4 kernels.
sleep 3 is executed everytime

Now with my patch, only sleep 1 is executed. Where is that slower?


Gruss Olaf

-- 
USB is for mice, FireWire is for men!


-------------------------------------------------------
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
_______________________________________________
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: [PATCH] queue usb hotplug events

[Olaf Hering]

 On Sat, Jun 07, David Brownell wrote:

> Olaf Hering wrote:
> >Hi,
> >
> >there is a hardcoded sleep 3 in the usb.agent. But this is wrong,
> >because the kernel runs all hotplug events at once for a new hub. The
> >result is that every event still runs in parallel, just 3 seconds later.
> 
> That "sleep" is a workaround for "uhci" and "usb-uhci" bugs:

you can change that to sleep 1 or sleep 42 or sleep $largenum, they will
still run in parallel. This one solves it.

        touch "${REMOVER}.queue.$$"
        sleep 3 & MAX_DELAY=$!
        while [ -d /proc/$MAX_DELAY ] ; do
                lockfiles=`ls -t /var/run/usb/*.queue.* 2>/dev/null`
                pid=${lockfiles##*.}
                test "$pid" = "$$" && { debug_mesg pid $$ proceeds ; break; }
                test "$lockfiles" = "" && { debug_mesg all lockfiles gone ; break; }
                debug_mesg wait 1 second for pid $pid
                sleep 0.5
        done

Now you have zero delay for the first event.

-- 
USB is for mice, FireWire is for men!


-------------------------------------------------------
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
_______________________________________________
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: [PATCH] queue usb hotplug events

[David Brownell]

Olaf Hering wrote:
 >>>there is a hardcoded sleep 3 in the usb.agent. But this is wrong,
 >>>because the kernel runs all hotplug events at once for a new hub. The
 >>>result is that every event still runs in parallel, just 3 seconds later.
 >>
 >>That "sleep" is a workaround for "uhci" and "usb-uhci" bugs:
 >
 >
 > you can change that to sleep 1 or sleep 42 or sleep $largenum, they will
 > still run in parallel. This one solves it.

Running parallel isn't a bug, doesn't need to be changed.
Typically the agents just finish faster that way.





-------------------------------------------------------
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
_______________________________________________
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: [PATCH] queue usb hotplug events

[Olaf Hering]

 On Sun, Jun 08, Olaf Hering wrote:

>         touch "${REMOVER}.queue.$$"

It should be '> "${REMOVER}.queue.$$"' to avoid yet another process.


Gruss Olaf

-- 
USB is for mice, FireWire is for men!


-------------------------------------------------------
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
_______________________________________________
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: [PATCH] queue usb hotplug events

[Olaf Hering]

 On Sun, Jun 08, David Brownell wrote:

> Olaf Hering wrote:
> >>>there is a hardcoded sleep 3 in the usb.agent. But this is wrong,
> >>>because the kernel runs all hotplug events at once for a new hub. The
> >>>result is that every event still runs in parallel, just 3 seconds later.
> >>
> >>That "sleep" is a workaround for "uhci" and "usb-uhci" bugs:
> >
> >
> > you can change that to sleep 1 or sleep 42 or sleep $largenum, they will
> > still run in parallel. This one solves it.
> 
> Running parallel isn't a bug, doesn't need to be changed.
> Typically the agents just finish faster that way.

You could drop the sleep 3 at all if you argue that way.

-- 
USB is for mice, FireWire is for men!


-------------------------------------------------------
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
_______________________________________________
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