On Fri, 20 Oct 2006, Laurent Pinchart wrote:
> > Did anything ever come out of all this? Was the problem located and was
> > the firmware fixed?
>
> As far as I know, no :-(
>
> Martin has finished his thesis and doesn't work at Logitech anymore. He told
> me before leaving that the firmware d
Hi Alan,
> > > > In ALL of the control transfers that I looked at, the time difference
> > > > between the SETUP packet and the first IN or OUT packet was never
> > > > more than 5 or 6 microseconds. The time difference between the ACK
> > > > of the SETUP and the first IN/OUT is around 2 or 3 mi
On Thu, 5 Oct 2006, Alan Stern wrote:
> On Wed, 4 Oct 2006 [EMAIL PROTECTED] wrote:
>
> > > In ALL of the control transfers that I looked at, the time difference
> > > between the SETUP packet and the first IN or OUT packet was never more
> > > than 5 or 6 microseconds. The time difference betwe
On Wed, 4 Oct 2006 [EMAIL PROTECTED] wrote:
> > In ALL of the control transfers that I looked at, the time difference
> > between the SETUP packet and the first IN or OUT packet was never more
> > than 5 or 6 microseconds. The time difference between the ACK of the
> > SETUP and the first IN/OUT
> > > > What's interesting to see is that for most failed requests the
first
> > data
> > > > transaction follows within less than 500 microseconds after the
SETUP
> > > > transaction. It's not always the case, but it definitely seems to
help
> > > > trigger the problem.
> > >
> > > The same thing
On Wed, 4 Oct 2006 [EMAIL PROTECTED] wrote:
> Hey Alan,
>
> Thanks a lot for looking at the traces!
>
> > > What's interesting to see is that for most failed requests the first
> data
> > > transaction follows within less than 500 microseconds after the SETUP
> > > transaction. It's not always t
Hey Alan,
Thanks a lot for looking at the traces!
> > What's interesting to see is that for most failed requests the first
data
> > transaction follows within less than 500 microseconds after the SETUP
> > transaction. It's not always the case, but it definitely seems to help
> > trigger the prob
On Wed, 4 Oct 2006 [EMAIL PROTECTED] wrote:
> Hi Alan,
>
> I've gathered a few example traces here:
...
> The traces were all made without a hub.
>
> What's interesting to see is that for most failed requests the first data
> transaction follows within less than 500 microseconds after the SETUP
On Tuesday 03 October 2006 11:04 am, Alan Stern wrote:
> On Mon, 2 Oct 2006, David Brownell wrote:
>
> >
> > > In principle it's possible to change ehci-hcd so that the SETUP
> > > transaction of a control transfer is sent in a different microframe from
> > > the following IN/OUT transactions. I
On Mon, 2 Oct 2006, David Brownell wrote:
>
> > In principle it's possible to change ehci-hcd so that the SETUP
> > transaction of a control transfer is sent in a different microframe from
> > the following IN/OUT transactions. In practice it might be a painfully
> > difficult change to write.
>
> > You probably won't get too far trying to understand Windows' behavior by
> > asking questions on a Linux mailing list. :-)
>
> Well, many talented Linux programmers know more about Windows than Windows
> programmers themselves :-)
And assuming that were true, I think they'd still not want
> In principle it's possible to change ehci-hcd so that the SETUP
> transaction of a control transfer is sent in a different microframe from
> the following IN/OUT transactions. In practice it might be a painfully
> difficult change to write.
Probably just mark only one TD active at a time, and
On Mon, 2 Oct 2006, Laurent Pinchart wrote:
> > > > > It
> > > > > seems the bug is never triggered when using Microsoft Windows, so I
> > > > > suspect that Linux uses a faster scheduler. Is there a way to hack
> > > > > the USB scheduler to make it split control transfers across USB
> > > > > fr
> > > > It
> > > > seems the bug is never triggered when using Microsoft Windows, so I
> > > > suspect that Linux uses a faster scheduler. Is there a way to hack
> > > > the USB scheduler to make it split control transfers across USB
> > > > frames ? We would like to test if the hardware bug would
On Fri, 29 Sep 2006, Laurent Pinchart wrote:
> > > It
> > > seems the bug is never triggered when using Microsoft Windows, so I
> > > suspect that Linux uses a faster scheduler. Is there a way to hack the
> > > USB scheduler to make it split control transfers across USB frames ? We
> > > would lik
> > I'm developing a Linux driver for a Logitech USB webcam. A few users
> > reported that the webcam stopped responding under some conditions. After
> > some investigation, I found out that the device either timed-out or
> > returned a STALL handshake during a control transfer on endpoint 0.
> >
>
> > Logitech has been kind enough to investigate the problem. It seems a
> > hardware bug is triggered when the control transfer transactions are sent
> > "too fast". Preliminary results show that the hardware misses the second
> > transaction in a control transfer when both the SETUP and IN/OUT
>
On Wednesday 27 September 2006 1:11 pm, Laurent Pinchart wrote:
> Logitech has been kind enough to investigate the problem. It seems a hardware
> bug is triggered when the control transfer transactions are sent "too fast".
> Preliminary results show that the hardware misses the second transactio
On Wed, 27 Sep 2006, Laurent Pinchart wrote:
> Hi everybody,
>
> I'm developing a Linux driver for a Logitech USB webcam. A few users reported
> that the webcam stopped responding under some conditions. After some
> investigation, I found out that the device either timed-out or returned a
> ST
Hi everybody,
I'm developing a Linux driver for a Logitech USB webcam. A few users reported
that the webcam stopped responding under some conditions. After some
investigation, I found out that the device either timed-out or returned a
STALL handshake during a control transfer on endpoint 0.
Lo
20 matches
Mail list logo
