Yes, there IS a bug of the d12 driver.
All the ep were added to the gadget.ep_list including
ep0, which cause the ep0->driver_data not pointing to
gadgetfs device after activate_ep_files() function,
and once writing to ep0 on setup_in, the fake dev
crashed everything.
Thanks for your help...
> 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
> > >
>
>
>
___________________________________________________________
雅虎邮箱传递新年祝福，个性贺卡送亲朋！
http://cn.mail.yahoo.com/gc/index.html?entry=5&souce=mail_mailletter_tagline
-
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
