On Monday 18 February 2008, hui zhuu wrote:
> Hi Dave,
> 
> After the stress test and backport gadget code from
> 2.6.24 to my current 2.6.20 version, the problem
> remains .

Suggesting more strongly that it's the "d12" driver
which is making trouble.


> It always reports error when responding to the
> following setup request:
> 
> SETUP 80.06 v0300 i0000 l00ff

See below ... this is *after* the problem.  The fact
that you see an error with this request is a side
effect of the bug.


> usb.c always fails at replying to this request, it
> reports:
> 
> write string data: Device or resource busy
> ep0 read after poll: Level 2 halted 
> 
> I don't know if AIO is mandantory for this
> enumaration, as I did not use AIO.
> 
> I also got something DEBUG message from gadgetfs as
> the following:
> 
> SETUP 80.06 v0300 i0000 l00ff
> gadgetfs: delegate req80.06 v0300 i0000 l255
> gadgetfs: event[1] = 3
> gadgetfs: ep0 request busy!

Did you look at the gadgetfs source to see *WHY* that
message was emitted?  It explains much of what the
problem is.  Specifically, setup_out_ready is set.

And a simple examination of the code shows that there's
only one way that can be nonzero:  there was an ep0out
request, and its data didn't get up to userspace yet.

What request was that?  Is your d12 driver handling
its part of that request correctly ... including the
code paths which clear that flag after it gets set?

- Dave



> gadgetfs: ep0in stall
> 
> Any suggestion for me?
> 
> Thanks ...
> 
> 
> --- David Brownell <[EMAIL PROTECTED]>写道:
> 
> > On Thursday 14 February 2008, hui zhuu wrote:
> > > > > Thanks, anyway, how can I find the if version
> > of
> > > > the
> > > > > gadgetfs.h is wrong?
> > > > 
> > > > Use the version of the header from the kernel
> > that
> > > > you're running with.
> > > 
> > > I just did that, the problem is still there.
> > > 
> > > This is strange, as our d12 driver works ok with
> > the
> > > serial/ether/file_storage gadget, from this point
> > can
> > > I suppose it is sufficient to hooks up with
> > gadgetfs?
> > 
> > It could be.  Does g_zero work well in stress test
> > mode?
> > (That is, running all the tests in the test script,
> > for
> > several days at a time ... try it over this
> > weekend.)
> > 
> > Usually the problem with gadgetfs has been a mode
> > for
> > handling control transfers that isn't widely used
> > ...
> > except in gadgetfs, and g_file_storage.
> > 
> >  
> > > The gadget code i am working with is form 2.6.20.4
> > > kernel tree, I think it's pretty new. Did I miss
> > > anything else?
> > 
> > I've not used gadgetfs much lately, beyond just a
> > quick sanity test on 2.6.24 to sort out that one
> > issue (which turned out to be in userspace).
> > 
> > So, all I can say for sure is:  try 2.6.24 and see
> > if that works for you too.
> > 
> > - Dave
> > 


-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to