On Tue, 4 Jun 2013, victor yeo wrote:
> > I have no idea what the CV test is doing. If you can get a log from
> > the CV program, that would help.
>
> The CV log is attached (Dev_desc_test-Address state.html). Is it helpful?
It doesn't help very much. Can you get a more verbose log, one that
lists all the transfers?
It looks like the problem could be that the host and the gadget don't
agree on what packets have been sent and received. If that's true,
you may need to use a USB bus analyzer to diagnose it.
> > There is one strange thing in the middle of the gadget log:
> >
> > This shows a Get-Config-Descriptor request followed by a
> > Get-Device-Descriptor request. What is the reason for the line saying
> > "g_file_storage gadget: in handle_exception loop"? There should not
> > have been any exceptions.
>
> The "g_file_storage gadget: in handle_exception loop" is from the DBG
> that i added in fsg_main_thread(). I also attach an updated gadget log
> file, which corresponds to the CV log. I cannot figure out this part
> of the code about handle_exception(). Is a signal received and
> handle_exception() is supposed to perform some action?
>
> if (exception_in_progress(fsg) || signal_pending(current)) {
> handle_exception(fsg);
> DBG(fsg, "in handle_exception loop\n");
> continue;
> }
Okay, now I understand. The "in handle_exception loop" line in the log
is from an exception that happened earlier, before the
Get-Config-Descriptor request. The exception was caused by the
preceding request, Set-Config: The USB_REQ_SET_CONFIGURATION case in
standard_setup_req() calls raise_exception(). The handle_exception()
routine then does the real work of changing the configuration, by
calling do_set_config(). The Get-Config-Descriptor request just
happened to arrive before your DBG line was executed.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
