On Wed, 1 Mar 2006, Marc Singer wrote:
> My question is simple. How can I inspect a dump from USBMON and
> indentify something that is a wrong result? Assuming that the message
> order produced by the UHCI driver is correct (it's too late to go
> buying a hub right now), and I suspect that it is
On Wed, 1 Mar 2006, David Brownell wrote:
> In this case you are. The HCD is *not allowed* to start one transfer before
> the preceding one finishes. I have good reason to believe that neither
> OHCI nor EHCI will misbehave in that way. UHCI has in the past had some
> issues there ... so it's w
On Wed, 1 Mar 2006, Marc Singer wrote:
> I'm going through the code paths and finding that the reason it stalls
> on DESCRIPTOR requests is that that is all it can do. It only
> processes a couple of different types of setup messages, DESCRIPTORS
> are not among them.
Be careful when you say thi
On Wed, 1 Mar 2006, Marc Singer wrote:
> On Wed, Mar 01, 2006 at 04:56:51PM -0800, Pete Zaitcev wrote:
> > On Wed, 1 Mar 2006 16:27:56 -0800, Marc Singer <[EMAIL PROTECTED]> wrote:
> >
> > > 0:15.261198 # 10 S Ci 009:00 s 80 00 0002 ( DtH st dv
> > > GET_STATUS ) --- 2 <
> > > 0:15.2
On Wed, 1 Mar 2006, Marc Singer wrote:
> I'd appreciate some feedback about this. I'm attaching the raw log as
> well as showing the output of a simple parser. There are a couple of
> things that I don't know of they should bother me.
>
> In the following output, the time stamps lead the line a
On Wed, Mar 01, 2006 at 08:51:19PM -0800, Pete Zaitcev wrote:
> On Wed, 1 Mar 2006 19:30:16 -0800, David Brownell <[EMAIL PROTECTED]> wrote:
> > On Wednesday 01 March 2006 5:53 pm, Pete Zaitcev wrote:
> > > On Wed, 1 Mar 2006 17:36:17 -0800, Marc Singer <[EMAIL PROTECTED]> wrote:
> > >
> > > > Its
On Wed, 1 Mar 2006 19:30:16 -0800, David Brownell <[EMAIL PROTECTED]> wrote:
> On Wednesday 01 March 2006 5:53 pm, Pete Zaitcev wrote:
> > On Wed, 1 Mar 2006 17:36:17 -0800, Marc Singer <[EMAIL PROTECTED]> wrote:
> >
> > > Its response to #11 is what is
> > > broken. It may be getting confused by
On Wed, Mar 01, 2006 at 07:30:16PM -0800, David Brownell wrote:
> The thing to understand about test #10 is that it's _trying_ to do things
> that UDC drivers often get wrong. Trying to trigger races ("both events
> in one IRQ"), trying to issue back-to-back faults so that improper cleanup
> of on
On Wednesday 01 March 2006 5:53 pm, Pete Zaitcev wrote:
> On Wed, 1 Mar 2006 17:36:17 -0800, Marc Singer <[EMAIL PROTECTED]> wrote:
>
> > Its response to #11 is what is
> > broken. It may be getting confused by the second status request *or*
> > it may have sent the STALL (is that the -32?) befor
On Wed, 1 Mar 2006 18:36:57 -0800, Marc Singer <[EMAIL PROTECTED]> wrote:
>0:33.300555 # 16 s> Ci 009:00 s 80 06 0200 0400 ( DtH st dv
> GET_DESCRIPTOR [CONFIGURATION 0] ) --- 1024 <
> ...
>0:33.322552 # 16 0002ff00 00fa0705 02024000 00070581 0240
>
> What is the -121?
I do n
On Wed, Mar 01, 2006 at 06:07:47PM -0800, Pete Zaitcev wrote:
> On Wed, 1 Mar 2006 18:00:31 -0800, Marc Singer <[EMAIL PROTECTED]> wrote:
>
> > > Why don't you enable tracing in UDC or whatever that thing is?
> > > I gather that you are hacking on the device, so what does it see?
> >
> > Enabling
On Wed, 1 Mar 2006 18:00:31 -0800, Marc Singer <[EMAIL PROTECTED]> wrote:
> > Why don't you enable tracing in UDC or whatever that thing is?
> > I gather that you are hacking on the device, so what does it see?
>
> Enabling DEBUG in the UDC driver makes it break even worse. Alan
> Stern recommen
On Wed, Mar 01, 2006 at 05:53:14PM -0800, Pete Zaitcev wrote:
> On Wed, 1 Mar 2006 17:36:17 -0800, Marc Singer <[EMAIL PROTECTED]> wrote:
>
> > Its response to #11 is what is
> > broken. It may be getting confused by the second status request *or*
> > it may have sent the STALL (is that the -32?)
On Wed, 1 Mar 2006 17:36:17 -0800, Marc Singer <[EMAIL PROTECTED]> wrote:
> Its response to #11 is what is
> broken. It may be getting confused by the second status request *or*
> it may have sent the STALL (is that the -32?) before it received the
> second GET_STATUS.
If queueing in HCD works w
On Wed, Mar 01, 2006 at 04:56:51PM -0800, Pete Zaitcev wrote:
> On Wed, 1 Mar 2006 16:27:56 -0800, Marc Singer <[EMAIL PROTECTED]> wrote:
>
> > 0:15.261198 # 10 S Ci 009:00 s 80 00 0002 ( DtH st dv GET_STATUS
> > ) --- 2 <
> > 0:15.261201 # 11 S Ci 009:00 s 80 06 0600 000a ( DtH
On Wed, 1 Mar 2006 16:27:56 -0800, Marc Singer <[EMAIL PROTECTED]> wrote:
> 0:15.261198 # 10 S Ci 009:00 s 80 00 0002 ( DtH st dv GET_STATUS )
> --- 2 <
> 0:15.261201 # 11 S Ci 009:00 s 80 06 0600 000a ( DtH st dv
> GET_DESCRIPTOR [DEVICE_QUALIFIER 0] ) --- 10 <
> ...
> 0:15.2
I performed a second capture using the driver as present in the kernel
archive with a couple of changes so that it would compile. The
results are similar.
What isn't clear to me is what this apparent error code means and who
is sending it.
My annotated capture has these entries:
0:15.261198 #
I'd appreciate some feedback about this. I'm attaching the raw log as
well as showing the output of a simple parser. There are a couple of
things that I don't know of they should bother me.
In the following output, the time stamps lead the line and are
computed as offsets from the first value.
18 matches
Mail list logo
