Rogers, On Mon, Apr 11, 2011 at 9:10 AM, Roger Quadros <roger.quadros@xxxxxxxxx> wrote: > > On 04/06/2011 10:11 PM, ext Alan Stern wrote: >> >> On Wed, 6 Apr 2011, Sonasath, Moiz wrote: >> >>> All, >>> >>> I am working on android kernel based on K35, and I see these bunch of >>> device configure failures. Any pointers would really help. >> >> Which gadget driver are you using? >> >> Have you enabled verbose debugging in the gadget driver? >> > > I've kind of come to realize why this is happening. > > It is a timing related issue. MSC tests issues two set configurations and set interface (alt 0) and immediately follow with a CBW. > > In the current composite framework + f_mass_storage setup, the actual enabling and disabling of endpoints is done in a background thread, while the setup requests are allowed to complete through composite.c. > > (notice that DELAYED_RESPONSE is not correctly implemented here as in file_storage.c) > > The CBW is received by the controller but due to large latency in scheduling the thread to process the CONFIG_STATE_CHANGE state, the endpoints get reset after the CBW is received, instead of before, thus loosing the CBW. Yes, I agree with your analysis, as this definitely seems to be some timing issue as very often I do see all the tests passing or all the Device configure tests don't fail only one or two fails. Also, for the failure cases I observe that fsg_main_thread(), get_next_command() just keeps on waiting for the CBW (which is getting lost perhaps as per your explanation) and hence the tests fail. Do you mean DELAYED_STATUS ? Any suggestions as to how can we solve this issue? > > -- > regards, > -roger Regards Moiz -- Regards Moiz Sonasath Android Kernel Team -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
