On Thu, 17 Oct 2013, Victor Yeo wrote: > > Here's another experiment you can try. In do_set_config(), just after > > the "rc = do_set_interface(fsg, -1);" line, add a statement saying > > > > INFO(fsg, "fsg->config %d new_config %d\n", > > fsg->config, new_config); > > > > In standard_setup_req(), change the "VDBG(fsg, "get configuration\n");" > > line to > > > > INFO(fsg, "get configuration %d\n", fsg->config); > > > > Then let's see what shows up in the device's system log. > > > I have added in the INFO statements. You added the second INFO statement in the wrong place. I said to change the line that says VDBG(fsg, "get configuration\n"); but instead you changed the line that says VDBG(fsg, "get configuration descriptor\n"); > After that, the log files are > captured during device enumeration. After i made the modification for > the second test, the USBCV software cannot see the device. However, > enumeration can be completed. > > The analyzer log and device log of enumeration for the second test are > attached. What does "and NAK endpoint" on line 73 of the device log mean? > From the log, i still cannot find out who call the UDC > driver queue function when Set-Config request is received. Add a dump_stack(); statement to the UDC driver queue function, for the case where the function was called for endpoint 0. That will tell you where the call came from. > Follow-up on USBCV test using the normal UDC driver. The analyzer log > and device log are attached. This is even more mysterious. In the analyzer log, the Get-Config-Descriptor transfer starting with packet 46548 (line 70) doesn't correspond to anything in the device log. But the device clearly did send a reply, shown in packet 52406 (line 81). Following that, the transfer starting with packet 52415 (line 94 in the analyzer log) corresponds to line 2129 in the device log. But the device log shows a 32-byte response was sent (lines 2133-2134) whereas the analyzer log shows a 0-byte response (packet 142758, line 105). Notice the large jump in the packet numbers: 52415 to 142758. I wonder why the device took so long to reply? There's also a 0.13-second jump in the timestamps between those two packets, but the device log doesn't show this delay. In addition, the analyzer timestamps show a 6-second jump between packets 142762 and 194829, but the device log shows less than 1.5 seconds between lines 2134 and and 2138. > In device log, line 2152, host sends Get-Config request, line 2156, > host sends Set-Config request. Before Set-Config request is completed, > in line 2158, host sends Get-Config request again. Yep. In between is another one of those "and NAK endpoint" lines. > However, in analyzer log, we can see that: > Set-Config request status stage is completed before host sends > Get-Config request again. > > There is inconsistency between device and analyzer log. Some unknown > code completes the Set-Config status stage. You have to find out what that unknown code really is. Alan Stern -- 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
