All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Erdfelt <johannes@erdfelt.com>
To: linux-hotplug@vger.kernel.org
Subject: Re: [linux-usb-devel] [PATCH] fix some hubs and hid devices at startup
Date: Wed, 15 May 2002 21:37:23 +0000	[thread overview]
Message-ID: <marc-linux-hotplug-102149870712604@msgid-missing> (raw)
In-Reply-To: <marc-linux-hotplug-101588456410451@msgid-missing>

On Wed, May 15, 2002, Olaf Hering <olh@suse.de> wrote:
> On Fri, Mar 15, Greg KH wrote:
> 
> > On Thu, Mar 14, 2002 at 02:21:47PM +0100, Olaf Hering wrote:
> > > > The problem looks like the usbdevfs calls are happening at the same time
> > > > the hid driver is also talking to the device.
> > > > 
> > > > Olaf, is this what your log messages show?
> > > 
> > > It seems so. I think a more correct fix would be a lock in the usbcore
> > > code to hold usbdevfs requests when "some bus action" is going on, like
> > > this renumbering. You said there is no lock right now for this case?
> > 
> > This is correct and has been on the list of things to fix in the usb
> > code for a while.
> 
> What is the status of this bug in the hotplug related functions? We
> added a "sleep 3" in the add routing in usb.rc, but that can only be a
> workaround.
> 
> My idea was that we queue the hotplug events somehow and wait for all
> "bus traffic" to complete, the stuff that occours when the usb-uhci
> driver is loaded. Something like
> insmod usbcore;insmod usb-uhci;modprobe hid;insmod keybdev;insmod mousedev
> should work. And it did not with 2.4.19pre2/3, I got timeouts. However,
> typing the commands manually to get some delay, and it worked. So I
> think that it is not strictly related to usbdevfs, that might be another
> bug.
> 
> However, after reading the whole thread again, it seems that queuing the
> events is maybe not the best solution. What should be done to get this
> fixed? (The delay and locking should be in the kernel and not in the
> hotplug package).

Well, it shouldn't be giving you back ETIMEDOUT. That's indicitive of
another bug, not the queueing.

However, it looks like uhci.c (and probably usb-uhci.c too since the
code was based on it) didn't correctly match control pipe's and prevent
2 URB's from being queued, 1 in and 1 out.

Can you try this patch?

It should atleast start returning -ENXIO (-6 on x86).

JE

--- linux-2.4.19-pre8.orig/drivers/usb/uhci.c	Wed May 15 13:29:27 2002
+++ linux-2.4.19-pre8/drivers/usb/uhci.c	Wed May 15 13:27:52 2002
@@ -1470,9 +1470,14 @@
 
 		tmp = tmp->next;
 
-		if (u->dev = urb->dev && u->pipe = urb->pipe &&
-		    u->status = -EINPROGRESS)
-			return u;
+		if (u->dev = urb->dev && u->status = -EINPROGRESS) {
+			/* For control, ignore the direction */
+			if (usb_pipecontrol(urb->pipe) &&
+			    (u->pipe & ~USB_DIR_IN) = (urb->pipe & ~USB_DIR_IN))
+				return u;
+			else if (u->pipe = urb->pipe)
+				return u;
+		}
 	}
 
 	return NULL;

_______________________________________________________________

Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: bandwidth@sourceforge.net
_______________________________________________
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

  parent reply	other threads:[~2002-05-15 21:37 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-03-11 22:08 [linux-usb-devel] [PATCH] fix some hubs and hid devices at startup Johannes Erdfelt
2002-03-12  0:20 ` David Brownell
2002-03-12 20:27 ` Greg KH
2002-03-12 20:29 ` Greg KH
2002-03-12 22:15 ` David Brownell
2002-03-12 22:52 ` Greg KH
2002-03-13  1:52 ` David Brownell
2002-03-14 13:21 ` Olaf Hering
2002-03-15 18:28 ` Greg KH
2002-05-15 20:25 ` David Brownell
2002-05-15 20:37 ` Olaf Hering
2002-05-15 21:37 ` Johannes Erdfelt [this message]
  -- strict thread matches above, loose matches on Subject: below --
2002-05-15 20:08 Olaf Hering

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=marc-linux-hotplug-102149870712604@msgid-missing \
    --to=johannes@erdfelt.com \
    --cc=linux-hotplug@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.