On Wed, 16 Oct 2013, Victor Yeo wrote: > Hi, > > > The text capture is incomplete. It is missing lots of packets. In > > particular, it is missing all the packets between 202489 and 202502. > > The missing packets are NAK, I added the NAK after Set-Config setup > stage. I hide the NAK when i export the packet capture to text format. They can't all be NAKs. The device won't send a NAK unless the host sends an IN first. > > Also, I don't understand the "Dir H(S)" part of the capture lines. > > What do they mean? They are present on every packet. > > Dir stands for direction, H is high speed, S is super speed. I guessed that "Dir" stands for "direction". But which direction? It doesn't say whether the packet goes to the host or to the device -- it just says "Dir". If "H" stands for "High speed" and "S" stands for "SuperSpeed", then "H(S)" stands for "High speed(SuperSpeed)". What does that mean? Also, why does the analyzer log sometimes list the contents of a DATA0 or DATA1 packet, but other times just say "Data(8 bytes)"? By the way, you didn't mention this earlier, but the analyzer log you sent before shows a problem in packet 157241. The gadget should have sent a config descriptor, but it sent an empty data packet. > > This was never the issue. I'm sure the DATA1 packet of the Set-Config > > was sent before the Get-Config request. The real question is whether > > the DATA1 packet was sent before the Set-Config request had been fully > > processed. > > > > To get more information, try adding > > > > msleep(100); > > > > just before the final "return rc;" line in do_set_config(). We should > > be able to see in the analyzer log if this 100-ms delay is present. > > After i added msleep(100) just before final line in do_set_config(), > the USB enumeration fails to complete normally. What happens, exactly? I have asked you many times in the past to provide more debugging information. Without information, I can't help you. In this case, you should have provided the kernel log from the gadget and the analyzer log. > > Here's a second test you can try. In handle_exception(), the > > FSG_STATE_CONFIG_CHANGE case, comment out the > > > > ep0_queue(fsg); > > > > line. Without that line the Set-Config request should time out, > > because the gadget will never complete the status stage. If the > > request does complete normally, it will prove that the UDC driver isn't > > working right. > > After i comment out the ep0_queue(fsg) in FSG_STATE_CONFIG_CHANGE case > of handle_exception(), the request does complete, but takes more time > to complete. And UDC driver queue function is still being called after > the Set-Config request. Provide more information! Where does the UDC driver queue function get called from? 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. 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
