On Fri, 22 Aug 2003, John Levon wrote:
> On Wed, Aug 20, 2003 at 12:01:31PM -0400, Alan Stern wrote:
>
> > > + usb_set_interface(interface_to_usbdev(iface),
> > > + iface->altsetting[0].desc.bInterfaceNumber,
> > > + 0);
> >
> > If a program is trying to use an in
On Tue, 19 Aug 2003, John Levon wrote:
> On Tue, Aug 19, 2003 at 01:45:18PM -0700, David Brownell wrote:
>
> > On the other hand, I can imagine some of Alan's updates might
> > turn up bugs with drivers accessing endpoints that don't exist
>
> This could well be it; adding the hunk below causes
John Levon wrote:
On Tue, Aug 19, 2003 at 10:06:09AM -0700, David Brownell wrote:
No bright ideas beyond trying on non-UHCI hardware, sorry.
Here :
http://movementarian.org/usbhunks.diff
is the diff I have got so far from binary searching starting from test2.
Applying that diff to my tree ->
John Levon wrote:
Note the errno of 32 above. This appears to happen on an
ioctl(USBDEVFS_SUBMITURB) of the device with a USBDEVFS_URB_TYPE_BULK type.
Huh. Well, if it were control, that might be caused by
one of the UHCI bugfixes that aren't yet merged. It
caused control stalls to happen in cas
John Levon wrote:
The user-space driver is attempting to read from the device, and
apparently failing on its first attempt with an -EPIPE. The previous run
of "modem_run" seems to succeed though.
Nothing you sent suggests EPIPE ...
I see several patches to endpoint handling etc. in USB over the re
