Mine is compiled UHCI as per the output of the lspci -v.  Got a
usbsniffer and the command line options you want run (presuming it's a
software thing and not a hardware sniffer)?




Thus spake David Brownell ([EMAIL PROTECTED]):

> Robert L. Harris wrote:
> >Thus spake Greg KH ([EMAIL PROTECTED]):
> >>On Thu, Aug 07, 2003 at 06:44:25PM -0400, Robert L. Harris wrote:
> >>
> >>>Bus 001 Device 004: ID 04e6:0704 SCM Microsystems, Inc. 
> >>>cannot get string descriptor 1, error = Broken pipe(32)
> >>>cannot get string descriptor 2, error = Broken pipe(32)
> >>>cannot get string descriptor 5, error = Broken pipe(32)
> >>
> >>That's a busted device :(
> >>
> >>
> >>>Bus 001 Device 002: ID 0451:2046 Texas Instruments, Inc. TUSB2046 Hub
> >>> Language IDs: none (cannot get min. string descriptor; got len=-1,
> >>>error=32:Broken pipe)
> >>
> >>Hm, so is that.
> >
> >
> >I can access the device under Windows and back on a 2.4.20ish kernel.
> 
> 
> Alan Stern and I have been exchanging a bit of email offline...
> 
> It seems that the "uhci-hcd" driver is reporting some transfers
> as stalls (EPIPE, errno 32) that it shouldn't be.  Unclear why;
> someone needs a USB sniffer to show what's up.  But it is clear
> that the same device reports stalls with "uhci-hcd", yet it works
> without any errors when "ohci-hcd" is used.  Using OHCI vs UHCI
> being the only variable.
> 
> - Dave

:wq!
---------------------------------------------------------------------------
Robert L. Harris                     | GPG Key ID: E344DA3B
                                         @ x-hkp://pgp.mit.edu
DISCLAIMER:
      These are MY OPINIONS ALONE.  I speak for no-one else.

Life is not a destination, it's a journey.
  Microsoft produces 15 car pileups on the highway.
    Don't stop traffic to stand and gawk at the tragedy.

Attachment: pgp00000.pgp
Description: PGP signature

Reply via email to