On Mon, 14 Aug 2006, Greg KH wrote:
> > I think the best approach would be to put the entire second half of
> > hub_port_connect_change (i.e., the big loop that runs SET_CONFIG_TRIES
> > times) into the sub-thread. Then usb_new_device could be left as is,
> > which will avoid problems with HCDs r
esendet: Freitag, 11. August 2006 17:37
Betreff: Re: [linux-usb-devel] Device connect timing
> On Fri, 11 Aug 2006, Thorsten Wiedemer wrote:
>
> > Hi !
> >
> > Thanks for the quick answers !
> >
> > > You shouldn't make timing measurements based on wh
On Sat, Aug 12, 2006 at 10:57:13AM -0400, Alan Stern wrote:
> On Fri, 11 Aug 2006, Greg KH wrote:
> > > As I see it, there's no advantage in making register_root_hub run in a
> > > new thread. There _is_ an advantage in making the call from the hub
> > > driver run in a new thread, but there are
On Fri, 11 Aug 2006, Greg KH wrote:
> > As I see it, there's no advantage in making register_root_hub run in a
> > new thread. There _is_ an advantage in making the call from the hub
> > driver run in a new thread, but there are also dangers. Just as one
> > example, what's to prevent someone
On Fri, Aug 11, 2006 at 02:03:21PM -0400, Alan Stern wrote:
> On Fri, 11 Aug 2006, Greg KH wrote:
>
> > > This won't work right if an error occurs. The value you return to the
> > > caller of usb_new_device() reflects only errors in creating the new
> > > thread. It doesn't reflect any errors
On Fri, 11 Aug 2006, Greg KH wrote:
> > This won't work right if an error occurs. The value you return to the
> > caller of usb_new_device() reflects only errors in creating the new
> > thread. It doesn't reflect any errors the thread itself may encounter.
> >
> > So the caller won't realiz
On Fri, Aug 11, 2006 at 11:24:26AM -0400, Alan Stern wrote:
> On Fri, 11 Aug 2006, Greg KH wrote:
>
> > From: Greg Kroah-Hartman <[EMAIL PROTECTED]>
> > Subject: USB: create a new thread for every USB device found during the
> > probe sequence
> >
> > Might speed up some systems. If nothing els
On Fri, 11 Aug 2006, Thorsten Wiedemer wrote:
> Hi !
>
> Thanks for the quick answers !
>
> > You shouldn't make timing measurements based on when things show up in
> > /var/log/messages. That file is maintained by the syslog daemon, which
> > does not necessarily add entries as soon as they ar
On Fri, 11 Aug 2006, Greg KH wrote:
> From: Greg Kroah-Hartman <[EMAIL PROTECTED]>
> Subject: USB: create a new thread for every USB device found during the probe
> sequence
>
> Might speed up some systems. If nothing else, a bad driver should not
> take the whole USB subsystem down with it.
>
On Fri, Aug 11, 2006 at 08:46:54AM +0200, Thorsten Wiedemer wrote:
> Hi !
>
> > Yes, I'm playing around with some multi-threaded probing stuff right
> > now. I've got PCI working pretty well now, see the -mm kernel for the
> > patches if you want to test it out.
> >
> > However it's not going to
Hi !
> Yes, I'm playing around with some multi-threaded probing stuff right
> now. I've got PCI working pretty well now, see the -mm kernel for the
> patches if you want to test it out.
>
> However it's not going to directly translate over to the USB code, we
> have to limit probing to a per-devi
Hi !
Thanks for the quick answers !
> You shouldn't make timing measurements based on when things show up in
> /var/log/messages. That file is maintained by the syslog daemon, which
> does not necessarily add entries as soon as they are available. Instead
> you should use dmesg (there is a CONF
On Thu, Aug 10, 2006 at 05:18:54PM +0200, Thorsten Wiedemer wrote:
>
> This is perhaps a stupid question, but is there a possibility to speed up
> the connect handling (without rewriting the whole usb drivers ...) in the
> newer kernel ?
Yes, I'm playing around with some multi-threaded probing st
On Thu, 10 Aug 2006, Thorsten Wiedemer wrote:
> Hi list !
>
> We use a fairly large usb tree with about 12 hubs and 18 high speed devices
> to build a control surface.
> With kernel 2.6.8.1 it took about 8 seconds from plugin of the first hub
> (where all other hubs/devices are connected) to the
Hi list !
We use a fairly large usb tree with about 12 hubs and 18 high speed devices
to build a control surface.
With kernel 2.6.8.1 it took about 8 seconds from plugin of the first hub
(where all other hubs/devices are connected) to the root hub until all
hubs/devices where "found" and announced
15 matches
Mail list logo
