Summary:
(1) Windows 98 OK
(2) Data toggle problem?
Hi Dave, I used USB snoopy (also known as sniff usb) to watch
what happens under windows 98SE. As with the linux driver,
an urb is sent to endpoint 0x81; it typically won't ever come back
since it only comes back if the status of the ADSL line changes.
So we can think of the root hub as polling for it all
the time (I'm only guessing that the root hub does the polling,
I haven't read that bit of the specs yet!). The windows driver
also sends an urb over and over again to another endpoint
(50 times a second).
Then I plug in another USB device and watch what happens.
Nothing happens! No urbs fail, all continues just fine! In short,
there seems to be no problem whatsoever under windows 98SE.
On Wednesday 26 June 2002 22:56, David Brownell wrote:
> Duncan Sands wrote:
> >>>Question: why did the first urb complete with -EILSEQ when
> >>>the other device was plugged in?
> >>
> >>And also, why did it _keep_ doing that afterwards?
> >
> > This is presumably the same question.
>
> Likely so, but not necessarily.
>
> >>Can you tweak the "return -EILSEQ" to be more like
> >>
> >> { info ("status bits %08x", status); return -EILSEQ; }
> >>
> >>and see if perhaps some other status bit is more suggestive
> >>of the real problem. Maybe the data toggle got trashed, or
> >>something similar.
Indeed, maybe it is a data toggle problem. If that is so how can
I test it? Once the endpoint gets "stuck" (always returns -EILSEQ),
how can it be cleared?
I tried (with the endpoint stuck):
(1) usb_clear_halt. This had no effect. When I tried this I didn't check
to see whether it returned an error, so maybe it failed.
(2) usb_settoggle(dev, 1, 0, 0) followed by usb_clear_halt. This also
had no effect, however I remembered to check the usb_clear_halt return
value this time, and it always returns -ETIMEDOUT. So I guess the
usb_clear_halt just failed. But why?
Any ideas?
Duncan.
> > This always gives "status bits 00440000".
>
> Translates to stall and a crc/timeout, I think...
>
> I'm still not quite clear what's making that happen,
> but it does suggest that it might be important for
> the driver to clear the stall before expecting anything
> else. That's usb_clear_halt(), and I presume there's
> some "libusb" call you can make to get at that through
> the USBDEVFS_CLEAR_HALT ioctl.
>
> If that makes your driver behave again, then it'd seem to
> me there's a bug in the UHCI status processing ... neither
> UHCI driver looks like it'll flag endpoints as halted
> unless a stall is the _only_ error reported.
>
> Of course there might be some other bug lurking too, since
> it's not clear why that first error should ever happen, but
> discarding stall status doesn't seem correct.
>
> - Dave
>
> p.s. This failure mode is about what you'd expect to
> happen when a driver doesn't clear a stall on
> an endpoint ... the device would completely
> refuse to talk using that endpoint.
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: Jabber Inc.
> Don't miss the IM event of the season | Special offer for OSDN members!
> JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn
> _______________________________________________
> [EMAIL PROTECTED]
> To unsubscribe, use the last form field at:
> https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
No, I will not fix your computer.
http://thinkgeek.com/sf
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
