Re: Linux USB file storage gadget with new UDC
On Tue, 22 Oct 2013, Victor Yeo wrote: Hi, It looks like you didn't add the dump_stack() call to the UDC driver's queue function. You need to add it. The attached is the log of dump_stack() call in the UDC driver queue function, for the last few USB request in the USBCV device descriptor test � addressed state. From the log, after Set-Config request is received, the UDC driver queue function is not called. That function is called after Get-Config request is received. Interesting. This means the UDC hardware sent the DATA1 packet for the status stage even though the driver did not tell it to do so. Could this be a bug in the hardware? An alternative possibility is that the UDC driver doesn't do the right thing after calling fsg_setup. Perhaps when fsg_setup returns, the UDC driver always tells the hardware to send the DATA1 packet? I also share the pseudo code of the setup data valid processing, i suspect it may be related to the problem: receive setup data valid interrupt find out the usb request field (bmRequestType, bRequest, wValue, wIndex, wLength) if (USB_CLEAR_FEATURE_REQUEST) call usb_ep_queue() Don't you need to handle this in the hardware, just like USB_SET_FEATURE_REQUEST? USB_SET_FEATURE_REQUEST is handled in software. How come USB_SET_FEATURE_REQUEST is handled in software but USB_CLEAR_FEATURE_REQUEST is handled in hardware? That seems very strange. Why aren't they both handled the same way? 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
Re: Linux USB file storage gadget with new UDC
Hi, It looks like you didn't add the dump_stack() call to the UDC driver's queue function. You need to add it. The attached is the log of dump_stack() call in the UDC driver queue function, for the last few USB request in the USBCV device descriptor test – addressed state. From the log, after Set-Config request is received, the UDC driver queue function is not called. That function is called after Get-Config request is received. I also share the pseudo code of the setup data valid processing, i suspect it may be related to the problem: receive setup data valid interrupt find out the usb request field (bmRequestType, bRequest, wValue, wIndex, wLength) if (USB_CLEAR_FEATURE_REQUEST) call usb_ep_queue() Don't you need to handle this in the hardware, just like USB_SET_FEATURE_REQUEST? USB_SET_FEATURE_REQUEST is handled in software. Thanks, victor [ 83.61] : 80 06 00 02 00 00 09 00 [ 83.61] fsg_setup call ep0_queue Backtrace: [ 83.61] [c020c0fc] (dump_backtrace+0x0/0x110) from [c03eee04] (dump_stack+0x18/0x1c) [ 83.61] r6:0002 r5:c0d6f600 r4:c0da69c0 r3:bf02fa10 [ 83.61] [c03eedec] (dump_stack+0x0/0x1c) from [bf02fa2c] (kagen2_ep_queue+0x1c/0x7b4 [kagen2_udc]) [ 83.61] [bf02fa10] (kagen2_ep_queue+0x0/0x7b4 [kagen2_udc]) from [bf0390b8] (ep0_queue+0x28/0x60 [g_file_storage]) [ 83.61] [bf039090] (ep0_queue+0x0/0x60 [g_file_storage]) from [bf038e10] (fsg_setup+0x3a0/0x3d8 [g_file_storage]) [ 83.61] r5:c0e23e98 r4:c0d6f600 [ 83.61] [bf038a70] (fsg_setup+0x0/0x3d8 [g_file_storage]) from [bf02f8c0] (kagen2_irq+0x388/0x4d8 [kagen2_udc]) [ 83.61] [bf02f538] (kagen2_irq+0x0/0x4d8 [kagen2_udc]) from [c0249644] (handle_irq_event_percpu+0x30/0x178) [ 83.61] r7:0020 r6: r5:c049af70 r4:c0da6840 [ 83.61] [c0249614] (handle_irq_event_percpu+0x0/0x178) from [c02497ec] (handle_irq_event+0x60/0x7c) [ 83.61] [c024978c] (handle_irq_event+0x0/0x7c) from [c024bcac] (handle_edge_irq+0x114/0x16c) [ 83.61] r6:f5006000 r5: r4:c049af70 r3:f5006000 [ 83.61] [c024bb98] (handle_edge_irq+0x0/0x16c) from [c0249054] (generic_handle_irq+0x28/0x38) [ 83.61] r4:0020 r3:c024bb98 [ 83.61] [c024902c] (generic_handle_irq+0x0/0x38) from [c0209c2c] (handle_IRQ+0x68/0x8c) [ 83.61] r4:0020 r3:0040 [ 83.61] [c0209bc4] (handle_IRQ+0x0/0x8c) from [c0208410] (asm_do_IRQ+0x10/0x14) [ 83.61] r5:0013 r4:bf02f500 [ 83.61] [c0208400] (asm_do_IRQ+0x0/0x14) from [c0208f14] (__irq_svc+0x34/0xbc) [ 83.61] Exception stack(0xc0e23f60 to 0xc0e23fa8) [ 83.61] 3f60: 4000 0288001f c2886000 c0df2c00 c0df2c00 bf02f4d8 0013 [ 83.61] 3f80: c0e23fbc c0e22000 c0e23fa8 4001 bf02f500 [ 83.61] 3fa0: 0013 [ 83.61] [bf02f4d8] (chkbusy_thread+0x0/0x60 [kagen2_udc]) from [c022f868] (kthread+0x94/0xa0) [ 83.61] r4:c0d75d58 r3: [ 83.61] [c022f7d4] (kthread+0x0/0xa0) from [c021913c] (do_exit+0x0/0x6f0) [ 83.61] r6:c021913c r5:c022f7d4 r4:c0d75d58 [ 83.61] ept0 in queue len 0x9, buffer 0xc0d6f800 [ 83.61] : 09 02 20 00 01 01 04 c0 01 [ 83.62] : 80 08 00 00 00 00 01 00 [ 83.62] g_file_storage gadget: get configuration 1 1 [ 83.62] fsg_setup call ep0_queue Backtrace: [ 83.62] [c020c0fc] (dump_backtrace+0x0/0x110) from [c03eee04] (dump_stack+0x18/0x1c) [ 83.62] r6:c0da69c0 r5:c0d6f600 r4:c0da69c0 r3:bf02fa10 [ 83.62] [c03eedec] (dump_stack+0x0/0x1c) from [bf02fa2c] (kagen2_ep_queue+0x1c/0x7b4 [kagen2_udc]) [ 83.62] [bf02fa10] (kagen2_ep_queue+0x0/0x7b4 [kagen2_udc]) from [bf0390b8] (ep0_queue+0x28/0x60 [g_file_storage]) [ 83.62] [bf039090] (ep0_queue+0x0/0x60 [g_file_storage]) from [bf038e10] (fsg_setup+0x3a0/0x3d8 [g_file_storage]) [ 83.62] r5:c0e23e98 r4:c0d6f600 [ 83.62] [bf038a70] (fsg_setup+0x0/0x3d8 [g_file_storage]) from [bf02f8c0] (kagen2_irq+0x388/0x4d8 [kagen2_udc]) [ 83.62] [bf02f538] (kagen2_irq+0x0/0x4d8 [kagen2_udc]) from [c0249644] (handle_irq_event_percpu+0x30/0x178) [ 83.62] r7:0020 r6: r5:c049af70 r4:c0da6840 [ 83.62] [c0249614] (handle_irq_event_percpu+0x0/0x178) from [c02497ec] (handle_irq_event+0x60/0x7c) [ 83.62] [c024978c] (handle_irq_event+0x0/0x7c) from [c024bcac] (handle_edge_irq+0x114/0x16c) [ 83.62] r6:f5006000 r5: r4:c049af70 r3:f5006000 [ 83.62] [c024bb98] (handle_edge_irq+0x0/0x16c) from [c0249054] (generic_handle_irq+0x28/0x38) [ 83.62] r4:0020 r3:c024bb98 [ 83.62] [c024902c] (generic_handle_irq+0x0/0x38) from [c0209c2c] (handle_IRQ+0x68/0x8c) [ 83.62] r4:0020 r3:0040 [ 83.62] [c0209bc4] (handle_IRQ+0x0/0x8c) from [c0208410] (asm_do_IRQ+0x10/0x14) [ 83.62] r5:0013 r4:bf02f500 [ 83.62] [c0208400] (asm_do_IRQ+0x0/0x14)
Re: Linux USB file storage gadget with new UDC
On Fri, 18 Oct 2013, Victor Yeo wrote: With your input, i re-do the USBCV test, and put up a table for comparison between analyzer log and device log. The comparison result is saved as a jpeg file for easy viewing. The analyzer and device log are attached as well. Back to the Set-Config and Get-Config problem, from the analyser log, the set config setup stage and status stage are completed before the next get config request. In the device log, the last set config has not finished processing (handle_exception is not yet run), and the next get configuration comes. It looks like you didn't add the dump_stack() call to the UDC driver's queue function. You need to add it. I also share the pseudo code of the setup data valid processing, i suspect it may be related to the problem: receive setup data valid interrupt find out the usb request field (bmRequestType, bRequest, wValue, wIndex, wLength) if (USB_CLEAR_FEATURE_REQUEST) call usb_ep_queue() Don't you need to handle this in the hardware, just like USB_SET_FEATURE_REQUEST? else if (USB_SET_FEATURE_REQUEST or USB_SET_ADDRESS) handle in hardware else call fsg_setup() In device log, i can't see the output of dump_msg() in fsg_setup(). I wonder why? Probably because you forgot to #define DUMP_MSGS in addition to #define DEBUG. 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
Re: Linux USB file storage gadget with new UDC
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux USB file storage gadget with new UDC
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. 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. 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. 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. Thanks, Victor -- 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
Re: Linux USB file storage gadget with new UDC
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux USB file storage gadget with new UDC
On Mon, 14 Oct 2013, Victor Yeo wrote: Hi, Victor, if you can get hold of a USB bus analyzer, you would be able to see directly when the DATA1 packet does or does not get sent. I am in the process of getting a USB bus analyzer. No -- the problem is that the UDC completes the Set-Config request before it should. In other words, it sends the DATA1 packet when it really should send a NAK packet. In the status stage of Set-Config request, i make the driver sends the NAK packet after it receives the IN packet. However, the next Get-Config request is still sent out by host. With the USB bus analyzer, hopefully i can verify the packets. I am sorry for the three month delay. Today i got hold of the LeCroy USB bus analyzer to debug the USBCV Device Descriptor Test-Addressed State problem. The ascii text capture from the USB bus analyzer is attached. The text capture is incomplete. It is missing lots of packets. In particular, it is missing all the packets between 202489 and 202502. Also, I don't understand the Dir H(S) part of the capture lines. What do they mean? They are present on every packet. Basically, it is confirmed that DATA1 packet of the Set-Config is sent out before the Get-Config request.The timing sequence of the USB request packets is correct. 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. 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. 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
Re: Linux USB file storage gadget with new UDC
Hi, Victor, if you can get hold of a USB bus analyzer, you would be able to see directly when the DATA1 packet does or does not get sent. I am in the process of getting a USB bus analyzer. No -- the problem is that the UDC completes the Set-Config request before it should. In other words, it sends the DATA1 packet when it really should send a NAK packet. In the status stage of Set-Config request, i make the driver sends the NAK packet after it receives the IN packet. However, the next Get-Config request is still sent out by host. With the USB bus analyzer, hopefully i can verify the packets. Why haven't you turned on CONFIG_PRINTK_TIME on your gadget system? I have asked you several times to do this. Without CONFIG_PRINTK_TIME, there is no way to tell how long it took to reach this spot. Ok. I will turn CONFIG_PRINTK_TIME on for debugging. Thanks, victor -- 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
Re: Linux USB file storage gadget with new UDC
Hi, However, the USB-2 spec says (section 9.2.6.4) that devices should be able to carry out requests with no Data stage (such as Set-Config) within 50 ms. Does your gadget really take longer than that to handle the exception? To find out, collect a usbmon trace showing what happens when your new driver is plugged into a Linux host. I have set the NAK and stall the endpoint 0 after receiving Set-Config request, however, That doesn't make sense. Stalling the endpoint means sending a STALL packet. You can't send both a STALL and a NAK. Get-Config request is still sent out by USBCV host immediately. There should be at least a 50-ms delay, unless the UDC driver is doing something wrong. The latest usbmon trace is attached. From the trace, the timing is within 50ms from Set-Config request to the next request. Does your gadget really take longer than that to handle the exception? Yes, i think there is a delay before gadget calls the handle_exception() routine. So the problem is before handle_exception() of Set-Config request is called, the next request is sent out already by the host. So if the next request is Get-Config, it will not return the latest config value. As can be seen in the gadget driver log below, after Set-Config request is received, another two more requests are received before handle_exception() is called. If there is a way to call handle_exception() immediately after Set-Config request, it would be very helpful. g_file_storage gadget: ep0-setup, length 8: : 00 09 01 00 00 00 00 00 g_file_storage gadget: set configuration and stall endpoint g_file_storage gadget: ep0-setup, length 8: : 80 06 04 03 09 04 ff 00 g_file_storage gadget: get string descriptor ept0 in queue len 0x1a, buffer 0xc1297800 ep0_complete g_file_storage gadget: ep0-in, length 26: : 1a 03 53 00 65 00 6c 00 66 00 2d 00 70 00 6f 00 0010: 77 00 65 00 72 00 65 00 64 00 g_file_storage gadget: ep0-setup, length 8: : 80 06 05 03 09 04 ff 00 g_file_storage gadget: get string descriptor ept0 in queue len 0x1a, buffer 0xc1297800 ep0_complete g_file_storage gadget: ep0-in, length 26: : 1a 03 4d 00 61 00 73 00 73 00 20 00 53 00 74 00 0010: 6f 00 72 00 61 00 67 00 65 00 handle_exception begin handle_exception wait until handle_exception old_state 4 g_file_storage gadget: set interface 0 g_file_storage gadget: high-speed config #1 FSG_STATE_CONFIG_CHANGE 19 21 0 g_file_storage gadget: in handle_exception loop Thanks, victor -- 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
Re: Linux USB file storage gadget with new UDC
Hi, On Fri, Jul 12, 2013 at 04:20:04PM +0800, Victor Yeo wrote: However, the USB-2 spec says (section 9.2.6.4) that devices should be able to carry out requests with no Data stage (such as Set-Config) within 50 ms. Does your gadget really take longer than that to handle the exception? To find out, collect a usbmon trace showing what happens when your new driver is plugged into a Linux host. I have set the NAK and stall the endpoint 0 after receiving Set-Config request, however, That doesn't make sense. Stalling the endpoint means sending a STALL packet. You can't send both a STALL and a NAK. Get-Config request is still sent out by USBCV host immediately. There should be at least a 50-ms delay, unless the UDC driver is doing something wrong. The latest usbmon trace is attached. From the trace, the timing is within 50ms from Set-Config request to the next request. Does your gadget really take longer than that to handle the exception? Yes, i think there is a delay before gadget calls the handle_exception() routine. So the problem is before handle_exception() of Set-Config request is called, the next request is sent out already by the host. So if the next request is Get-Config, it will not return the latest config value. As can be seen in the gadget driver log below, after Set-Config request is received, another two more requests are received before handle_exception() is called. If there is a way to call handle_exception() immediately after Set-Config request, it would be very helpful. this is clearly a bug in your driver, host wouldn't send you more requests unless you acknowledge the previous one. You should be naking those extra requests until you're ready to ack. Frankly, we have quite a few UDC drivers passing all USBCV tests. -- balbi signature.asc Description: Digital signature
Re: Linux USB file storage gadget with new UDC
On Fri, 12 Jul 2013, Victor Yeo wrote: Hi, However, the USB-2 spec says (section 9.2.6.4) that devices should be able to carry out requests with no Data stage (such as Set-Config) within 50 ms. Does your gadget really take longer than that to handle the exception? To find out, collect a usbmon trace showing what happens when your new driver is plugged into a Linux host. I have set the NAK and stall the endpoint 0 after receiving Set-Config request, however, That doesn't make sense. Stalling the endpoint means sending a STALL packet. You can't send both a STALL and a NAK. Get-Config request is still sent out by USBCV host immediately. There should be at least a 50-ms delay, unless the UDC driver is doing something wrong. The latest usbmon trace is attached. From the trace, the timing is within 50ms from Set-Config request to the next request. Indeed, the Set-Config request completes after only 314 us, much less than 1 ms. Of course, that doesn't mean the gadget actually ran handle_exception() that quickly. More likely, the UDC told the host that the request had completed before it really was finished. Does your gadget really take longer than that to handle the exception? Yes, i think there is a delay before gadget calls the handle_exception() routine. So the problem is before handle_exception() of Set-Config request is called, the next request is sent out already by the host. So if the next request is Get-Config, it will not return the latest config value. No -- the problem is that the UDC completes the Set-Config request before it should. In other words, it sends the DATA1 packet when it really should send a NAK packet. 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
Re: Linux USB file storage gadget with new UDC
On Fri, 12 Jul 2013, Victor Yeo wrote: Does your gadget really take longer than that to handle the exception? Yes, i think there is a delay before gadget calls the handle_exception() routine. So the problem is before handle_exception() of Set-Config request is called, the next request is sent out already by the host. So if the next request is Get-Config, it will not return the latest config value. As can be seen in the gadget driver log below, after Set-Config request is received, another two more requests are received before handle_exception() is called. If there is a way to call handle_exception() immediately after Set-Config request, it would be very helpful. handle_exception() _does_ get called immediately after the Set-Config request. Or rather, the main thread gets woken up immediately, and if the CPU isn't busy doing something else then the main thread will run right away. g_file_storage gadget: ep0-setup, length 8: : 00 09 01 00 00 00 00 00 g_file_storage gadget: set configuration and stall endpoint g_file_storage gadget: ep0-setup, length 8: : 80 06 04 03 09 04 ff 00 g_file_storage gadget: get string descriptor ept0 in queue len 0x1a, buffer 0xc1297800 ep0_complete g_file_storage gadget: ep0-in, length 26: : 1a 03 53 00 65 00 6c 00 66 00 2d 00 70 00 6f 00 0010: 77 00 65 00 72 00 65 00 64 00 g_file_storage gadget: ep0-setup, length 8: : 80 06 05 03 09 04 ff 00 g_file_storage gadget: get string descriptor ept0 in queue len 0x1a, buffer 0xc1297800 ep0_complete g_file_storage gadget: ep0-in, length 26: : 1a 03 4d 00 61 00 73 00 73 00 20 00 53 00 74 00 0010: 6f 00 72 00 61 00 67 00 65 00 handle_exception begin Why haven't you turned on CONFIG_PRINTK_TIME on your gadget system? I have asked you several times to do this. Without CONFIG_PRINTK_TIME, there is no way to tell how long it took to reach this spot. handle_exception wait until handle_exception old_state 4 g_file_storage gadget: set interface 0 g_file_storage gadget: high-speed config #1 FSG_STATE_CONFIG_CHANGE 19 21 0 g_file_storage gadget: in handle_exception loop 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
Re: Linux USB file storage gadget with new UDC
On Fri, 12 Jul 2013, Felipe Balbi wrote: As can be seen in the gadget driver log below, after Set-Config request is received, another two more requests are received before handle_exception() is called. If there is a way to call handle_exception() immediately after Set-Config request, it would be very helpful. this is clearly a bug in your driver, host wouldn't send you more requests unless you acknowledge the previous one. I agree; the UDC must have told the host that the request was already complete. You should be naking those extra requests until you're ready to ack. Well, that's not quite right. Devices cannot NAK new control requests; a NAK is not a valid response to a SETUP packet. Frankly, we have quite a few UDC drivers passing all USBCV tests. 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
Re: Linux USB file storage gadget with new UDC
On Fri, Jul 12, 2013 at 10:46:48AM -0400, Alan Stern wrote: You should be naking those extra requests until you're ready to ack. Well, that's not quite right. Devices cannot NAK new control requests; a NAK is not a valid response to a SETUP packet. there would be no SETUP request if he properly delays his status phase. -- balbi signature.asc Description: Digital signature
Re: Linux USB file storage gadget with new UDC
On Fri, 12 Jul 2013, Felipe Balbi wrote: On Fri, Jul 12, 2013 at 10:46:48AM -0400, Alan Stern wrote: You should be naking those extra requests until you're ready to ack. Well, that's not quite right. Devices cannot NAK new control requests; a NAK is not a valid response to a SETUP packet. there would be no SETUP request if he properly delays his status phase. Exactly. Victor, if you can get hold of a USB bus analyzer, you would be able to see directly when the DATA1 packet does or does not get sent. 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
Re: Linux USB file storage gadget with new UDC
Hi, May i know which part of the do_set_config() or do_set_interface() has to be run in process context? Well, it's not exactly true that the routine has to run in process context. More accurately, it has to run at a time when the main thread isn't using any of the endpoints or request structures, because do_set_interface() deallocates the requests and disables the endpoints. For example, if the main thread was in the middle of executing a SCSI command, do_set_config() would have to wait until it finished. The easiest way to do this is by the exception technique. That way do_set_config() is called by the main thread itself, so it knows the main thread isn't using those structures. Thanks. The USBCV test has tight timing requirement. Once Set-Config request is sent out, USBCV sends out Get-Config request to get the config value immediately. At that time, gadget driver has not yet done the handle_exception. So Get-Config request returns old config value, and USBCV declares the test failed. Please see the log below. Is there any way to speed up the handle_exception or to ask the USBCV host to not send out Get-Config immediately? I have set the NAK and stall the endpoint 0 after receiving Set-Config request, however, Get-Config request is still sent out by USBCV host immediately. g_file_storage gadget: ep0-setup, length 8: : 00 09 00 00 00 00 00 00 g_file_storage gadget: set configuration NAK and stall endpoint g_file_storage gadget: ep0-setup, length 8: : 80 08 00 00 00 00 01 00 g_file_storage gadget: get configuration ept0 in queue len 0x1, buffer 0xc1289800 ep0_complete g_file_storage gadget: ep0-in, length 1: : 01 after kagen2_ep_queue kagen2_ep_queue 31 512 31 [kagen2_ep_queue] 43425355 89d40868 g_file_storage gadget: bulk-out, length 31: : 55 53 42 43 68 08 d4 89 00 00 00 00 00 00 0a 35 0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 g_file_storage gadget: SCSI command: SYNCHRONIZE CACHE; Dc=10, Dn=0; Hc=10, Hn=0 attention condition g_file_storage gadget: after calling do_scsi_command handle_exception begin handle_exception wait until handle_exception old_state 4 g_file_storage gadget: reset config g_file_storage gadget: reset interface FSG_STATE_CONFIG_CHANGE 52 53 0 g_file_storage gadget: in handle_exception loop g_file_storage gadget: in fsg-running loop g_file_storage gadget: in fsg-running loop thanks, victor -- 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
Re: Linux USB file storage gadget with new UDC
On Thu, 11 Jul 2013, Victor Yeo wrote: Thanks. The USBCV test has tight timing requirement. Once Set-Config request is sent out, USBCV sends out Get-Config request to get the config value immediately. At that time, gadget driver has not yet done the handle_exception. So Get-Config request returns old config value, and USBCV declares the test failed. Please see the log below. Is there any way to speed up the handle_exception No. or to ask the USBCV host to not send out Get-Config immediately? I am not at all familiar with USBCV, but I doubt it. However, the USB-2 spec says (section 9.2.6.4) that devices should be able to carry out requests with no Data stage (such as Set-Config) within 50 ms. Does your gadget really take longer than that to handle the exception? To find out, collect a usbmon trace showing what happens when your new driver is plugged into a Linux host. I have set the NAK and stall the endpoint 0 after receiving Set-Config request, however, That doesn't make sense. Stalling the endpoint means sending a STALL packet. You can't send both a STALL and a NAK. Get-Config request is still sent out by USBCV host immediately. There should be at least a 50-ms delay, unless the UDC driver is doing something wrong. 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
Re: Linux USB file storage gadget with new UDC
Hi, However, the USB-2 spec says (section 9.2.6.4) that devices should be able to carry out requests with no Data stage (such as Set-Config) within 50 ms. Does your gadget really take longer than that to handle the exception? To find out, collect a usbmon trace showing what happens when your new driver is plugged into a Linux host. I have set the NAK and stall the endpoint 0 after receiving Set-Config request, however, That doesn't make sense. Stalling the endpoint means sending a STALL packet. You can't send both a STALL and a NAK. Get-Config request is still sent out by USBCV host immediately. There should be at least a 50-ms delay, unless the UDC driver is doing something wrong. The latest usbmon trace is attached. From the trace, the timing is within 50ms from Set-Config request to the next request. Does your gadget really take longer than that to handle the exception? Yes, i think there is a delay before gadget calls the handle_exception() routine. So the problem is before handle_exception() of Set-Config request is called, the next request is sent out already by the host. So if the next request is Get-Config, it will not return the latest config value. Thanks, victor usbmon_july12.log Description: Binary data
Re: Linux USB file storage gadget with new UDC
Hi, Yes, this should be the root cause. For the setup stage of Set-Config request, the UDC driver can handle it well. But for the status stage of Set-Config request, somehow it is not handled correctly. When UDC driver receives the endpoint 0 IN token, it only clears the interrupt request. It will not send the Data1 packet unless usb_ep_queue() is called. And yet it _does_ send the packet before usb_ep_queue() is called. I am still studying how Data1 packet is sent out, from the log, usb_ep_queue() is not called, i have no idea now. DELAYED_STATUS tells fsg_setup() not to call ep0_queue(). It means that the request isn't finished yet, so the status isn't known. The status will be reported later, when the request is finished. handle_exception() is used for things that cannot be carried out in interrupt context. fsg_setup() runs in an interrupt handler, so it can't call do_set_config() or do_set_interface() -- those routines need to run in process context. Therefore the USB_REQ_SET_CONFIGURATION code raises an exception; when the fsg thread handles the exception, it calls do_set_config(). May i know which part of the do_set_config() or do_set_interface() has to be run in process context? Thanks, Victor -- 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
Re: Linux USB file storage gadget with new UDC
On Fri, 5 Jul 2013, Victor Yeo wrote: May i know which part of the do_set_config() or do_set_interface() has to be run in process context? Well, it's not exactly true that the routine has to run in process context. More accurately, it has to run at a time when the main thread isn't using any of the endpoints or request structures, because do_set_interface() deallocates the requests and disables the endpoints. For example, if the main thread was in the middle of executing a SCSI command, do_set_config() would have to wait until it finished. The easiest way to do this is by the exception technique. That way do_set_config() is called by the main thread itself, so it knows the main thread isn't using those structures. 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
Re: Linux USB file storage gadget with new UDC
Hi, I can't tell what's going on in your log. Look at the FSG_STATE_CONFIG_CHANGE case in handle_exception(). Here's the code: rc = do_set_config(fsg, new_config); if (fsg-ep0_req_tag != exception_req_tag) break; if (rc != 0)// STALL on errors fsg_set_halt(fsg, fsg-ep0); else// Complete the status stage ep0_queue(fsg); break; It calls do_set_config(). After that, fsg-ep0_req_tag should be equal to exception_req_tag and rc should be equal to 0. Therefore the code will call ep0_queue(), which calls usb_ep_queue(). I found out from printk, the fsg-ep0_req_tag and exception_req_tag are not equal, and rc is 0. In standard_setup_req(), case USB_REQ_SET_CONFIGURATION, once i add the following code if (w_value == 0) fsg-config = 0; just before the break; statement, the Device Descriptor Test-Addressed State can pass. It seems that Get-Config request from host cannot wait, so i have to return the latest config value in response to the request. Thanks, victor In fact, the Device Descriptor Test-Addressed State sometimes passes, sometimes fails after my modification. What is the reason of DELAYED_STATUS in USB_REQ_SET_CONFIGURATION, and the use of handle_exception() to call do_set_config()? Thanks, victor -- 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
Re: Linux USB file storage gadget with new UDC
On Wed, 3 Jul 2013, Victor Yeo wrote: Hi, I can't tell what's going on in your log. Look at the FSG_STATE_CONFIG_CHANGE case in handle_exception(). Here's the code: rc = do_set_config(fsg, new_config); if (fsg-ep0_req_tag != exception_req_tag) break; if (rc != 0)// STALL on errors fsg_set_halt(fsg, fsg-ep0); else// Complete the status stage ep0_queue(fsg); break; It calls do_set_config(). After that, fsg-ep0_req_tag should be equal to exception_req_tag and rc should be equal to 0. Therefore the code will call ep0_queue(), which calls usb_ep_queue(). I found out from printk, the fsg-ep0_req_tag and exception_req_tag are not equal, Than either there is a bug in the UDC (or the UDC driver), or else the host doesn't wait for the Set-Config request to complete before sending the next request. What were the values of fsg-ep0_req_tag and exception_req_tag? By searching through the code in file_storage.c, you can easily see that fsg-ep0_req_tag gets set in only one place: the first line of fsg_setup(). It is a counter -- it goes up by one every time a new SETUP packet is received, marking the start of a new control transfer. You can also see that handle_exception() sets exception_req_tag to the value of fsg-exception_req_tag, and raise_exception() sets fsg-exception_req_tag to the value of fsg-ep0_req_tag. This means that exception_req_tag holds the counter value as of the time the exception started. If the values are different, it means that another control transfer started (fsg_setup() was called) between the time when the original exception was raised and the time when it was handled. If the UDC is working correctly, the only way for this to happen is if the host sends another control request without waiting for the first one to finish. and rc is 0. In standard_setup_req(), case USB_REQ_SET_CONFIGURATION, once i add the following code if (w_value == 0) fsg-config = 0; just before the break; statement, the Device Descriptor Test-Addressed State can pass. It seems that Get-Config request from host cannot wait, so i have to return the latest config value in response to the request. Almost certainly, the problem is that the UDC told the host that the Set-Config request was finished before it should have. The host thought the request was finished, so it sent the next request -- the Get-Config -- but the gadget driver was still carrying out the Set-Config. In fact, the Device Descriptor Test-Addressed State sometimes passes, sometimes fails after my modification. What is the reason of DELAYED_STATUS in USB_REQ_SET_CONFIGURATION, and the use of handle_exception() to call do_set_config()? DELAYED_STATUS tells fsg_setup() not to call ep0_queue(). It means that the request isn't finished yet, so the status isn't known. The status will be reported later, when the request is finished. handle_exception() is used for things that cannot be carried out in interrupt context. fsg_setup() runs in an interrupt handler, so it can't call do_set_config() or do_set_interface() -- those routines need to run in process context. Therefore the USB_REQ_SET_CONFIGURATION code raises an exception; when the fsg thread handles the exception, it calls do_set_config(). When your UDC driver calls the gadget driver's .setup() function, how does it handle the return value? 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
Re: Linux USB file storage gadget with new UDC
Hi,
Than either there is a bug in the UDC (or the UDC driver), or else the
host doesn't wait for the Set-Config request to complete before sending
the next request. What were the values of fsg-ep0_req_tag and
exception_req_tag?
From the printk added, the values of fsg-ep0_req_tag and exception_req_tag
are:
fsg-ep0_req_tag 163, exception_req_tag 161
fsg-ep0_req_tag 168, exception_req_tag 167
fsg-ep0_req_tag 176, exception_req_tag 173
By searching through the code in file_storage.c, you can easily see
that fsg-ep0_req_tag gets set in only one place: the first line of
fsg_setup(). It is a counter -- it goes up by one every time a new
SETUP packet is received, marking the start of a new control transfer.
You can also see that handle_exception() sets exception_req_tag to
the value of fsg-exception_req_tag, and raise_exception() sets
fsg-exception_req_tag to the value of fsg-ep0_req_tag. This means
that exception_req_tag holds the counter value as of the time the
exception started.
If the values are different, it means that another control transfer
started (fsg_setup() was called) between the time when the original
exception was raised and the time when it was handled. If the UDC is
working correctly, the only way for this to happen is if the host sends
another control request without waiting for the first one to finish.
and rc is 0. In standard_setup_req(), case
USB_REQ_SET_CONFIGURATION, once i add the following code
if (w_value == 0)
fsg-config = 0;
just before the break; statement, the Device Descriptor
Test-Addressed State can pass. It seems that Get-Config request from
host cannot wait, so i have to return the latest config value in
response to the request.
Almost certainly, the problem is that the UDC told the host that the
Set-Config request was finished before it should have. The host
thought the request was finished, so it sent the next request -- the
Get-Config -- but the gadget driver was still carrying out the
Set-Config.
Yes, this should be the root cause. For the setup stage of Set-Config
request, the UDC driver can handle it well. But for the status stage
of Set-Config request, somehow it is not handled correctly. When UDC
driver receives the endpoint 0 IN token, it only clears the interrupt
request. It will not send the Data1 packet unless usb_ep_queue() is
called.
Somehow, before handle_exception() gets the chance to call
do_set_config(), host sends next request.
DELAYED_STATUS tells fsg_setup() not to call ep0_queue(). It means
that the request isn't finished yet, so the status isn't known. The
status will be reported later, when the request is finished.
handle_exception() is used for things that cannot be carried out in
interrupt context. fsg_setup() runs in an interrupt handler, so it
can't call do_set_config() or do_set_interface() -- those routines need
to run in process context. Therefore the USB_REQ_SET_CONFIGURATION
code raises an exception; when the fsg thread handles the exception, it
calls do_set_config().
When your UDC driver calls the gadget driver's .setup() function, how
does it handle the return value?
The code is as below:
status = dev-driver-setup(dev-gadget, usb_ctrlrequest);
if (status 0)
{
dev-protocol_stall = 1;
}
else if (status == (DELAYED_STATUS))
{
/*NAK the IN packet from host*/
}
Thanks,
victor
--
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
Re: Linux USB file storage gadget with new UDC
On Thu, 4 Jul 2013, Victor Yeo wrote:
Hi,
Than either there is a bug in the UDC (or the UDC driver), or else the
host doesn't wait for the Set-Config request to complete before sending
the next request. What were the values of fsg-ep0_req_tag and
exception_req_tag?
From the printk added, the values of fsg-ep0_req_tag and exception_req_tag
are:
fsg-ep0_req_tag 163, exception_req_tag 161
fsg-ep0_req_tag 168, exception_req_tag 167
fsg-ep0_req_tag 176, exception_req_tag 173
This means the host sent 2, 1, and 3 (respectively) control requests
before the first request was finished.
Yes, this should be the root cause. For the setup stage of Set-Config
request, the UDC driver can handle it well. But for the status stage
of Set-Config request, somehow it is not handled correctly. When UDC
driver receives the endpoint 0 IN token, it only clears the interrupt
request. It will not send the Data1 packet unless usb_ep_queue() is
called.
And yet it _does_ send the packet before usb_ep_queue() is called.
When your UDC driver calls the gadget driver's .setup() function, how
does it handle the return value?
The code is as below:
status = dev-driver-setup(dev-gadget, usb_ctrlrequest);
if (status 0)
{
dev-protocol_stall = 1;
}
else if (status == (DELAYED_STATUS))
{
/*NAK the IN packet from host*/
}
Th else if part is wrong; it should just be an else. As long as
status = 0, the value doesn't matter.
In fact, the UDC driver shouldn't even know what DELAYED_STATUS is.
DELAYED_STATUS is supposed to be private, internal to the
file_storage.c file.
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
Re: Linux USB file storage gadget with new UDC
Hi, No, that's not right. Set-Config has only two stages, Setup and Status; there is no Data stage. The flow is: Host Device - Setup Packet --- | - Data0 Packet --- |== Setup stage Ack Packet -- | - In Packet -- | Data1 Packet |== Status stage - Ack Packet - | ACK the Status stage of an OUT control transfer, is it referring to the Third ACK packet? So UDC driver should ACK only after Data1 packet is sent via the usb_ep_queue()? I meant the Data1 packet above. The UDC driver should not send this packet until the gadget driver tells it to (by calling usb_ep_queue). Until then, it should send NAK in respond to the In packet. Is the Data1 packet above containing no data, such as this? PID !PID CRC I do not see the gadget driver calling usb_ep_queue() for sending the Data1 packet. Please see the log below. Is there similar code in net2280.c handle_stat0_irqs() that handles Set-Config? g_file_storage gadget: ep0-setup, length 8: : 00 09 00 00 00 00 00 00 g_file_storage gadget: set configuration after kagen2_ep_queue kagen2_ep_queue 31 64 31 [kagen2_ep_queue] 43425355 899e1008 g_file_storage gadget: bulk-out, length 31: : 55 53 42 43 08 10 9e 89 00 00 00 00 00 00 0a 35 0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 g_file_storage gadget: SCSI command: SYNCHRONIZE CACHE; Dc=10, Dn=0; Hc=10, Hn=0 g_file_storage gadget: ep0-setup, length 8: : 80 08 00 00 00 00 01 00 g_file_storage gadget: get configuration ept0 in queue len 0x1, buffer 0xc1289800 ep0_complete g_file_storage gadget: ep0-in, length 1: : 01 attention condition Thanks, victor -- 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
Re: Linux USB file storage gadget with new UDC
On Tue, 2 Jul 2013, Victor Yeo wrote: Hi, No, that's not right. Set-Config has only two stages, Setup and Status; there is no Data stage. The flow is: Host Device - Setup Packet --- | - Data0 Packet --- |== Setup stage Ack Packet -- | - In Packet -- | Data1 Packet |== Status stage - Ack Packet - | ACK the Status stage of an OUT control transfer, is it referring to the Third ACK packet? So UDC driver should ACK only after Data1 packet is sent via the usb_ep_queue()? I meant the Data1 packet above. The UDC driver should not send this packet until the gadget driver tells it to (by calling usb_ep_queue). Until then, it should send NAK in respond to the In packet. Is the Data1 packet above containing no data, such as this? PID !PID CRC Yes. I do not see the gadget driver calling usb_ep_queue() for sending the Data1 packet. Please see the log below. Is there similar code in net2280.c handle_stat0_irqs() that handles Set-Config? net2280.c does not handle Set-Config; it passes those requests to the gadget driver. g_file_storage gadget: ep0-setup, length 8: : 00 09 00 00 00 00 00 00 g_file_storage gadget: set configuration after kagen2_ep_queue kagen2_ep_queue 31 64 31 [kagen2_ep_queue] 43425355 899e1008 g_file_storage gadget: bulk-out, length 31: : 55 53 42 43 08 10 9e 89 00 00 00 00 00 00 0a 35 0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 g_file_storage gadget: SCSI command: SYNCHRONIZE CACHE; Dc=10, Dn=0; Hc=10, Hn=0 g_file_storage gadget: ep0-setup, length 8: : 80 08 00 00 00 00 01 00 g_file_storage gadget: get configuration ept0 in queue len 0x1, buffer 0xc1289800 ep0_complete g_file_storage gadget: ep0-in, length 1: : 01 attention condition I can't tell what's going on in your log. Look at the FSG_STATE_CONFIG_CHANGE case in handle_exception(). Here's the code: rc = do_set_config(fsg, new_config); if (fsg-ep0_req_tag != exception_req_tag) break; if (rc != 0)// STALL on errors fsg_set_halt(fsg, fsg-ep0); else// Complete the status stage ep0_queue(fsg); break; It calls do_set_config(). After that, fsg-ep0_req_tag should be equal to exception_req_tag and rc should be equal to 0. Therefore the code will call ep0_queue(), which calls usb_ep_queue(). You can add some debugging printk statements to make sure it really does behave this way. 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
Re: Linux USB file storage gadget with new UDC
Hi, No, i don't see that (Set-Config request with a config value of 0) Well, then I don't know where the problem is, but obviously the problem occurred before the gadget driver was involved. Either the host sent a wrong packet, or more likely the UDC received the packet incorrectly. Yes, UDC driver has bug. After modifying it, it can receive Set-Config request with a config value of 0. However, the device descriptor test - addressed state still fails. Please see the attached log. The Set-Config request with a config value of 0 is the second last USB request sent from the host. The last USB request is Get-Config, which still returns config value of 1. Thanks, victor # dmesg -c g_file_storage gadget: disconnect or port reset handle_exception begin handle_exception wait until handle_exception old_state 5 g_file_storage gadget: in handle_exception loop g_file_storage gadget: in fsg-running loop g_file_storage gadget: disconnect or port reset handle_exception begin handle_exception wait until handle_exception old_state 5 g_file_storage gadget: in handle_exception loop g_file_storage gadget: in fsg-running loop g_file_storage gadget: ep0-setup, length 8: : 80 06 00 01 00 00 12 00 g_file_storage gadget: get device descriptor exit C ept0 in queue len 0x12, buffer 0xc1289800 ep0_complete g_file_storage gadget: ep0-in, length 18: : 12 01 00 02 00 00 00 40 25 05 a5 a4 33 03 01 02 0010: 00 01 USB_RECIP_DEVICE 0x2 fa is 0x2 exit A g_file_storage gadget: ep0-setup, length 8: : 80 06 00 01 00 00 12 00 g_file_storage gadget: get device descriptor ept0 in queue len 0x12, buffer 0xc1289800 ep0_complete g_file_storage gadget: ep0-in, length 18: : 12 01 00 02 00 00 00 40 25 05 a5 a4 33 03 01 02 0010: 00 01 g_file_storage gadget: ep0-setup, length 8: : 80 06 00 02 00 00 09 00 g_file_storage gadget: get configuration descriptor ept0 in queue len 0x9, buffer 0xc1289800 ep0_complete g_file_storage gadget: ep0-in, length 9: : 09 02 20 00 01 01 04 c0 01 g_file_storage gadget: ep0-setup, length 8: : 00 09 01 00 00 00 00 00 g_file_storage gadget: set configuration g_file_storage gadget: ep0-setup, length 8: : 80 06 00 02 00 00 09 00 g_file_storage gadget: get configuration descriptor ept0 in queue len 0x9, buffer 0xc1289800 ep0_complete g_file_storage gadget: ep0-in, length 9: : 09 02 20 00 01 01 04 c0 01 handle_exception begin handle_exception wait until handle_exception old_state 4 g_file_storage gadget: ep0-setup, length 8: : 80 06 00 02 00 00 20 00 g_file_storage gadget: get configuration descriptor ept0 in queue len 0x20, buffer 0xc1289800 ep0_complete g_file_storage gadget: ep0-in, length 32: : 09 02 20 00 01 01 04 c0 01 09 04 00 00 02 08 06 0010: 50 05 07 05 81 02 40 00 00 07 05 01 02 40 00 00 g_file_storage gadget: set interface 0 g_file_storage gadget: full-speed config #1 g_file_storage gadget: in handle_exception loop [start_transfer] 43425355 899e1008 ept1 out queue len 0x40, buffer 0xc0c44000 before kagen2_ep_queue g_file_storage gadget: disconnect or port reset after kagen2_ep_queue kagen2_ep_queue 31 64 31 [kagen2_ep_queue] 43425355 899e1008 g_file_storage gadget: bulk-out, length 31: : 55 53 42 43 08 10 9e 89 00 00 00 00 00 00 0a 35 0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 g_file_storage gadget: SCSI command: SYNCHRONIZE CACHE; Dc=10, Dn=0; Hc=10, Hn=0 attention condition g_file_storage gadget: after calling do_scsi_command handle_exception begin handle_exception wait until handle_exception old_state 5 g_file_storage gadget: reset config g_file_storage gadget: reset interface g_file_storage gadget: in handle_exception loop g_file_storage gadget: in fsg-running loop g_file_storage gadget: in fsg-running loop g_file_storage gadget: disconnect or port reset handle_exception begin handle_exception wait until handle_exception old_state 5 g_file_storage gadget: in handle_exception loop g_file_storage gadget: in fsg-running loop g_file_storage gadget: ep0-setup, length 8: : 80 06 00 01 00 00 12 00 g_file_storage gadget: get device descriptor exit C ept0 in queue len 0x12, buffer 0xc1289800 ep0_complete g_file_storage gadget: ep0-in, length 18: : 12 01 00 02 00 00 00 40 25 05 a5 a4 33 03 01 02 0010: 00 01 USB_RECIP_DEVICE 0x2 fa is 0x2 exit A g_file_storage gadget: ep0-setup, length 8: : 80 06 00 01 00 00 12 00 g_file_storage gadget: get device descriptor ept0 in queue len 0x12, buffer 0xc1289800 ep0_complete g_file_storage gadget: ep0-in, length 18: : 12 01 00 02 00 00 00 40 25 05 a5 a4 33 03 01 02 0010: 00 01 g_file_storage gadget: ep0-setup, length 8: : 80 06 00 02 00 00 09 00 g_file_storage gadget: get configuration descriptor ept0 in queue len 0x9, buffer 0xc1289800 ep0_complete g_file_storage gadget: ep0-in, length 9: : 09 02 20 00 01 01 04 c0 01 g_file_storage gadget: ep0-setup, length 8: : 00 09 01 00 00 00 00 00
Re: Linux USB file storage gadget with new UDC
Hi, No, i don't see that (Set-Config request with a config value of 0) Well, then I don't know where the problem is, but obviously the problem occurred before the gadget driver was involved. Either the host sent a wrong packet, or more likely the UDC received the packet incorrectly. Yes, UDC driver has bug. After modifying it, it can receive Set-Config request with a config value of 0. However, the device descriptor test - addressed state still fails. Please see the attached log. The Set-Config request with a config value of 0 is the second last USB request sent from the host. The last USB request is Get-Config, which still returns config value of 1. In gadget driver, do_set_config(), if new_config is 0, the new_config is not processed. So config value of zero will never be saved by gadget driver. Isn't it? Thanks, victor -- 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
Re: Linux USB file storage gadget with new UDC
On Mon, 1 Jul 2013, Victor Yeo wrote:
Yes, UDC driver has bug. After modifying it, it can receive Set-Config
request with a config value of 0. However, the device descriptor test
- addressed state still fails.
Please see the attached log. The Set-Config request with a config
value of 0 is the second last USB request sent from the host. The last
USB request is Get-Config, which still returns config value of 1.
This looks like another bug in the UDC driver. It performs the Status
stage of the Set-Config request before the gadget driver has finished
carrying out the request.
Notice that the USB_REQ_SET_CONFIGURATION case in standard_setup_req()
returns DELAYED_STATUS. As a result, fsg_setup() does not call
ep0_queue(), and so usb_ep_queue() doesn't get called. The UDC driver
is not supposed to ACK the Status stage of an OUT control transfer
until usb_ep_queue() is called.
In gadget driver, do_set_config(), if new_config is 0, the new_config
is not processed. So config value of zero will never be saved by
gadget driver. Isn't it?
Look at do_set_config():
/* Disable the single interface */
if (fsg-config != 0) {
DBG(fsg, reset config\n);
fsg-config = 0;
rc = do_set_interface(fsg, -1);
}
/* Enable the interface */
if (new_config != 0) {
...
}
return rc;
So if new_config is 0, fsg-config remains set to 0 and the
deconfiguration is processed by the do_set_interface() call.
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
Re: Linux USB file storage gadget with new UDC
Hi,
Yes, UDC driver has bug. After modifying it, it can receive Set-Config
request with a config value of 0. However, the device descriptor test
- addressed state still fails.
Please see the attached log. The Set-Config request with a config
value of 0 is the second last USB request sent from the host. The last
USB request is Get-Config, which still returns config value of 1.
This looks like another bug in the UDC driver. It performs the Status
stage of the Set-Config request before the gadget driver has finished
carrying out the request.
Notice that the USB_REQ_SET_CONFIGURATION case in standard_setup_req()
returns DELAYED_STATUS. As a result, fsg_setup() does not call
ep0_queue(), and so usb_ep_queue() doesn't get called. The UDC driver
is not supposed to ACK the Status stage of an OUT control transfer
until usb_ep_queue() is called.
May i verify my understanding of Set-Config request packet flow?
Host Device
--Setup Packet
--Data0 Packet
-Ack Packet-
-- In Packet
Data1 Packet
- Ack Packet -
- Out Packet
- Data1 Packet
Ack Packet -
ACK the Status stage of an OUT control transfer, is it referring to
the Third ACK packet? So UDC driver should ACK only after Data1 packet
is sent via the usb_ep_queue()?
In gadget driver, do_set_config(), if new_config is 0, the new_config
is not processed. So config value of zero will never be saved by
gadget driver. Isn't it?
Look at do_set_config():
/* Disable the single interface */
if (fsg-config != 0) {
DBG(fsg, reset config\n);
fsg-config = 0;
rc = do_set_interface(fsg, -1);
}
/* Enable the interface */
if (new_config != 0) {
...
}
return rc;
So if new_config is 0, fsg-config remains set to 0 and the
deconfiguration is processed by the do_set_interface() call.
Understand now. Thanks.
victor
--
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
Re: Linux USB file storage gadget with new UDC
On Tue, 2 Jul 2013, Victor Yeo wrote: This looks like another bug in the UDC driver. It performs the Status stage of the Set-Config request before the gadget driver has finished carrying out the request. Notice that the USB_REQ_SET_CONFIGURATION case in standard_setup_req() returns DELAYED_STATUS. As a result, fsg_setup() does not call ep0_queue(), and so usb_ep_queue() doesn't get called. The UDC driver is not supposed to ACK the Status stage of an OUT control transfer until usb_ep_queue() is called. May i verify my understanding of Set-Config request packet flow? Host Device --Setup Packet --Data0 Packet -Ack Packet- -- In Packet Data1 Packet - Ack Packet - - Out Packet - Data1 Packet Ack Packet - No, that's not right. Set-Config has only two stages, Setup and Status; there is no Data stage. The flow is: Host Device - Setup Packet --- | - Data0 Packet --- |== Setup stage Ack Packet -- | - In Packet -- | Data1 Packet |== Status stage - Ack Packet - | ACK the Status stage of an OUT control transfer, is it referring to the Third ACK packet? So UDC driver should ACK only after Data1 packet is sent via the usb_ep_queue()? I meant the Data1 packet above. The UDC driver should not send this packet until the gadget driver tells it to (by calling usb_ep_queue). Until then, it should send NAK in respond to the In packet. 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
Re: Linux USB file storage gadget with new UDC
Hi, g_file_storage gadget: ep0-setup, length 8: : 00 09 01 00 00 00 00 00 g_file_storage gadget: set configuration Yes, that is a Set-Config request with configuraiton value 1. You probably got hold of the wrong part of the log. Elsewhere there should be a Set-Config request with a config value of 0. No, i don't see that (Set-Config request with a config value of 0) g_file_storage gadget: ep0-setup, length 8: : 80 08 00 00 00 00 01 00 g_file_storage gadget: get configuration g_file_storage gadget: ep0-in, length 1: : 01 This is the correct response following the request above. You can test the gadget's behavior with a Linux host. To send a Set-Config request with value N, do echo N /sys/bus/usb/devices/.../bConfigurationValue where the ... part is replaced with the gadget's device path. When i use echo 0 /sys/bus/usb/devices/.../bConfigurationValue, there is no activity in gadget and UDC driver, and the gadget disappear from Linux host. If i use echo 1 /sys/bus/usb/devices/.../bConfigurationValue, the gadget is re-enumerated and re-appear in Linux host. I also observe in gadget driver, there is only one config descriptor with bConfigurationValue of 1. Is bConfigurationValue of 0 meant to disble the device? Thanks, Victor -- 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
Re: Linux USB file storage gadget with new UDC
On Fri, 28 Jun 2013, victor yeo wrote: Hi, g_file_storage gadget: ep0-setup, length 8: : 00 09 01 00 00 00 00 00 g_file_storage gadget: set configuration Yes, that is a Set-Config request with configuraiton value 1. You probably got hold of the wrong part of the log. Elsewhere there should be a Set-Config request with a config value of 0. No, i don't see that (Set-Config request with a config value of 0) Well, then I don't know where the problem is, but obviously the problem occurred before the gadget driver was involved. Either the host sent a wrong packet, or more likely the UDC received the packet incorrectly. g_file_storage gadget: ep0-setup, length 8: : 80 08 00 00 00 00 01 00 g_file_storage gadget: get configuration g_file_storage gadget: ep0-in, length 1: : 01 This is the correct response following the request above. You can test the gadget's behavior with a Linux host. To send a Set-Config request with value N, do echo N /sys/bus/usb/devices/.../bConfigurationValue where the ... part is replaced with the gadget's device path. When i use echo 0 /sys/bus/usb/devices/.../bConfigurationValue, there is no activity in gadget and UDC driver, and the gadget disappear from Linux host. There must have been _some_ activity, unless the UDC hardware handled the request by itself without telling the driver. More likely, the UDC driver did see the request and ignored it. The gadget didn't disappear from the Linux host. If it did disappear, the /sys/bus/usb/devices/.../bConfigurationValue file would be removed, so you wouldn't be able to write a 1 back to it. If i use echo 1 /sys/bus/usb/devices/.../bConfigurationValue, the gadget is re-enumerated and re-appear in Linux host. The gadget is not re-enumerated; it is re-configured (it goes from the Address state to the Configured state). I also observe in gadget driver, there is only one config descriptor with bConfigurationValue of 1. Is bConfigurationValue of 0 meant to disble the device? 0 doesn't disable the device; it de-configures the device (puts the device back in the Address state). See sections 9.1.1.4, 9.1.1.5, 9.2.3, and 9.4.7 in the USB 2.0 spec. 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
Re: Linux USB file storage gadget with new UDC
Hi, You should not be concerned about variables in the gadget driver. The problem is in the UDC driver. For some examples of what the UDC driver needs to do, look at handle_control_request() in drivers/usb/gadget/dummy_hcd.c or the switch (u.r.bRequest) statement of handle_stat0_irqs() in drivers/usb/gadget/net2280.c. Alan Stern I find some clue. From USB 2.0 Compliance Test Spec, quoted: Address State: 1. Put the device in the configured state following the procedure below. 2. Issue a valid Set Configuration command to the device with configuration value zero. 3. Issue a valid Get Configuration command to the device and verify that device responds with zero. I think the address state test in USB2CV fails because Set-Configuration actually set config #1 and Get-Configuration returns config #1. See the usb requests log below. It seems that the Set Configuration command from USB2CV is issued with config value of one. Isn't it? g_file_storage gadget: ep0-setup, length 8: : 00 09 01 00 00 00 00 00 g_file_storage gadget: set configuration g_file_storage gadget: ep0-setup, length 8: : 80 08 00 00 00 00 01 00 g_file_storage gadget: get configuration g_file_storage gadget: ep0-in, length 1: : 01 Thanks, victor -- 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
Re: Linux USB file storage gadget with new UDC
On Thu, 27 Jun 2013, victor yeo wrote: I find some clue. From USB 2.0 Compliance Test Spec, quoted: Address State: 1. Put the device in the configured state following the procedure below. 2. Issue a valid Set Configuration command to the device with configuration value zero. 3. Issue a valid Get Configuration command to the device and verify that device responds with zero. I think the address state test in USB2CV fails because Set-Configuration actually set config #1 and Get-Configuration returns config #1. See the usb requests log below. It seems that the Set Configuration command from USB2CV is issued with config value of one. Isn't it? g_file_storage gadget: ep0-setup, length 8: : 00 09 01 00 00 00 00 00 g_file_storage gadget: set configuration Yes, that is a Set-Config request with configuraiton value 1. You probably got hold of the wrong part of the log. Elsewhere there should be a Set-Config request with a config value of 0. g_file_storage gadget: ep0-setup, length 8: : 80 08 00 00 00 00 01 00 g_file_storage gadget: get configuration g_file_storage gadget: ep0-in, length 1: : 01 This is the correct response following the request above. You can test the gadget's behavior with a Linux host. To send a Set-Config request with value N, do echo N /sys/bus/usb/devices/.../bConfigurationValue where the ... part is replaced with the gadget's device path. 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
Re: Linux USB file storage gadget with new UDC
Hi, I re-attach the usbmon log. If possible, please show me which line indicates that usb_ep_set_wedge routine is not working, or how to look for the clue. Is it from the control transfer line? Here's an example: f4148f80 308532 S Bo:1:011:1 -115 31 = 55534243 0600 c000 861a 003f00c0 00 f4148f80 308652 C Bo:1:011:1 0 31 f14c5600 308676 S Bi:1:011:1 -115 192 f14c5600 3087787651 C Bi:1:011:1 -121 16 = 0f00 080a0400 f4148f80 3087787674 S Bi:1:011:1 -115 13 f4148f80 3087803018 C Bi:1:011:1 0 13 = 55534253 0600 b000 00 The last line should have failed with a -32 error code, because the IN endpoint is supposed to be halted at this point. I think the GET_STATUS request is not handled by the gadget driver. Isn't it so? That's right. Get-Status, Set-Feature, and Clear-Feature requests must be handled by the UDC driver. Alan Stern The fsg-state in gadget driver, is used for exception handling. Is there any variable to track the USB device state of Figure 9-1 of the USB 2.0 Spec? Now the gadget driver does not pass the USB2.0 CV - Get Device Descriptor - Address State test. So i am trying to find more information. Thanks, victor -- 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
Re: Linux USB file storage gadget with new UDC
On Wed, 26 Jun 2013, victor yeo wrote: The fsg-state in gadget driver, is used for exception handling. Is there any variable to track the USB device state of Figure 9-1 of the USB 2.0 Spec? Now the gadget driver does not pass the USB2.0 CV - Get Device Descriptor - Address State test. So i am trying to find more information. You should not be concerned about variables in the gadget driver. The problem is in the UDC driver. For some examples of what the UDC driver needs to do, look at handle_control_request() in drivers/usb/gadget/dummy_hcd.c or the switch (u.r.bRequest) statement of handle_stat0_irqs() in drivers/usb/gadget/net2280.c. 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
Re: Linux USB file storage gadget with new UDC
Hi, The problem is in UDC driver. i made the change, it is ok now. Good. I noticed that the usb_ep_set_wedge routine still isn't working right. You might try to fix that. Alan Stern Ok, is the usb_ep_set_wedge routine not working? I can't see that in the log file. Now, in USB 2.0 CV test, there is an error about GET_STATUS request, as shown below. g_file_storage gadget: ep0-setup, length 8: : 82 00 00 00 81 00 02 00 g_file_storage gadget: unknown control req 82.00 v i0081 l2 handle_setup status -95 I think the GET_STATUS request is not handled by the gadget driver. Isn't it so? thanks, victor -- 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
Re: Linux USB file storage gadget with new UDC
On Mon, 24 Jun 2013, victor yeo wrote: Hi, The problem is in UDC driver. i made the change, it is ok now. Good. I noticed that the usb_ep_set_wedge routine still isn't working right. You might try to fix that. Alan Stern Ok, is the usb_ep_set_wedge routine not working? I can't see that in the log file. It is not working. This can be seen in the usbmon log. Now, in USB 2.0 CV test, there is an error about GET_STATUS request, as shown below. g_file_storage gadget: ep0-setup, length 8: : 82 00 00 00 81 00 02 00 g_file_storage gadget: unknown control req 82.00 v i0081 l2 handle_setup status -95 I think the GET_STATUS request is not handled by the gadget driver. Isn't it so? That's right. Get-Status, Set-Feature, and Clear-Feature requests must be handled by the UDC driver. 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
Re: Linux USB file storage gadget with new UDC
Hi, Ok, is the usb_ep_set_wedge routine not working? I can't see that in the log file. It is not working. This can be seen in the usbmon log. I re-attach the usbmon log. If possible, please show me which line indicates that usb_ep_set_wedge routine is not working, or how to look for the clue. Is it from the control transfer line? Now, in USB 2.0 CV test, there is an error about GET_STATUS request, as shown below. g_file_storage gadget: ep0-setup, length 8: : 82 00 00 00 81 00 02 00 g_file_storage gadget: unknown control req 82.00 v i0081 l2 handle_setup status -95 I think the GET_STATUS request is not handled by the gadget driver. Isn't it so? That's right. Get-Status, Set-Feature, and Clear-Feature requests must be handled by the UDC driver. Alan Stern Should the UDC driver handle Get-Status before or after the call to fsg_setup()? thanks, victor f2e9da80 3086290883 S Ci:1:001:0 s a3 00 0001 0004 4 f2e9da80 3086290911 C Ci:1:001:0 0 4 = 0001 f2e9da80 3086290919 S Ci:1:001:0 s a3 00 0002 0004 4 f2e9da80 3086290923 C Ci:1:001:0 0 4 = 0001 f2e9da80 3086290927 S Ci:1:001:0 s a3 00 0003 0004 4 f2e9da80 3086290931 C Ci:1:001:0 0 4 = 0001 f2e9da80 3086290936 S Ci:1:001:0 s a3 00 0004 0004 4 f2e9da80 3086290940 C Ci:1:001:0 0 4 = 0001 f2e9da80 3086290944 S Ci:1:001:0 s a3 00 0005 0004 4 f2e9da80 3086290958 C Ci:1:001:0 0 4 = 03050400 f2e9da80 3086290963 S Ci:1:001:0 s a3 00 0006 0004 4 f2e9da80 3086290967 C Ci:1:001:0 0 4 = 0001 f6816a80 3086290972 S Ii:1:001:1 -115:2048 4 f2e9da80 3086291359 S Ci:1:001:0 s a3 00 0005 0004 4 f2e9da80 3086291366 C Ci:1:001:0 0 4 = 03050400 f2e9da80 3086291372 S Co:1:001:0 s 23 01 0012 0005 0 f2e9da80 3086291378 C Co:1:001:0 0 0 f2e9d100 3086307426 S Ci:1:001:0 s a3 00 0005 0004 4 f2e9d100 3086307441 C Ci:1:001:0 0 4 = 0305 f2e9d100 3086307450 S Ci:1:003:0 s 80 00 0002 2 f2e9d100 3086307599 C Ci:1:003:0 0 2 = 0300 f2e9d100 3086308101 S Co:1:003:0 s 00 01 0001 0 f2e9d100 3086308971 C Co:1:003:0 0 0 f2e9d100 3086308995 S Ci:1:003:0 s a3 00 0001 0004 4 f2e9d100 3086309344 C Ci:1:003:0 0 4 = 0001 f2e9d100 3086309362 S Ci:1:003:0 s a3 00 0002 0004 4 f2e9d100 3086309718 C Ci:1:003:0 0 4 = 01010100 f2e9d100 3086309736 S Co:1:003:0 s 23 01 0010 0002 0 f2e9d100 3086310093 C Co:1:003:0 0 0 f2e9d100 3086310110 S Ci:1:003:0 s a3 00 0003 0004 4 f2e9d100 3086310466 C Ci:1:003:0 0 4 = 0001 f2e9d100 3086310478 S Ci:1:003:0 s a3 00 0004 0004 4 f2e9d100 3086310842 C Ci:1:003:0 0 4 = 0001 f3369680 3086414872 S Ii:1:003:1 -115:2048 1 f33a1c00 3086414952 S Ci:1:003:0 s a3 00 0002 0004 4 f33a1c00 3086415358 C Ci:1:003:0 0 4 = 0101 f33a1c00 3086415413 S Co:1:003:0 s 23 03 0016 0002 0 f33a1c00 3086415717 C Co:1:003:0 0 0 f33a1c00 3086415763 S Co:1:003:0 s 23 03 0004 0002 0 f33a1c00 3086416093 C Co:1:003:0 0 0 f33a1600 3086430814 S Ci:1:003:0 s a3 00 0002 0004 4 f33a1600 3086431836 C Ci:1:003:0 0 4 = 03011000 f3369680 3086450282 C Ii:1:003:1 0:2048 1 = 04 f3369680 3086450297 S Ii:1:003:1 -115:2048 1 f33fa980 3086486796 S Co:1:003:0 s 23 01 0014 0002 0 f33fa980 3086487826 C Co:1:003:0 0 0 f33fa980 3086487934 S Ci:1:000:0 s 80 06 0100 0040 64 f33fa980 3086488571 C Ci:1:000:0 0 18 = 12010002 0040 2505a5a4 33030102 0001 f33fa980 3086488632 S Co:1:003:0 s 23 03 0004 0002 0 f33fa980 3086488943 C Co:1:003:0 0 0 f33fa080 3086503390 S Ci:1:003:0 s a3 00 0002 0004 4 f33fa080 3086503964 C Ci:1:003:0 0 4 = 03011000 f4147b80 3086558950 S Co:1:003:0 s 23 01 0014 0002 0 f4147b80 3086559441 C Co:1:003:0 0 0 f4147b80 3086559513 S Co:1:000:0 s 00 05 000b 0 f4147b80 3086559683 C Co:1:000:0 0 0 f2eeba00 3086578950 S Ci:1:011:0 s 80 06 0100 0012 18 f2eeba00 3086580189 C Ci:1:011:0 0 18 = 12010002 0040 2505a5a4 33030102 0001 f2eeba00 3086580259 S Ci:1:011:0 s 80 06 0600 000a 10 f2eeba00 3086580806 C Ci:1:011:0 0 10 = 0a060002 0040 0100 f2eeba00 3086580883 S Ci:1:011:0 s 80 06 0200 0009 9 f2eeb500 3086580900 S Co:1:003:0 s 23 03 0016 0202 0 f2eeb500 3086581180 C Co:1:003:0 0 0 f2eeba00 3086581558 C Ci:1:011:0 0 9 = 09022000 010104c0 01 f2eeba00 3086581604 S Ci:1:011:0 s 80 06 0200 0020 32 f2eeba00 3086582182 C Ci:1:011:0 0 32 = 09022000 010104c0 01090400 00020806 50050705 81024000 00070501 0240 f2eeba00 3086582259 S Ci:1:011:0 s 80 06 0300 00ff 255 f2eeba00 3086582933 C Ci:1:011:0 0 4 = 04030904 f2eeba00 3086583014 S Ci:1:011:0 s 80 06 0302 0409 00ff 255 f2eeba00 3086583558 C Ci:1:011:0 0 54 = 36034600 69006c00 65002d00 62006100 63006b00 65006400 20005300 74006f00 f2eeba00 3086583633 S Ci:1:011:0 s 80 06 0301 0409 00ff 255 f2eeba00 3086584558 C Ci:1:011:0 0 58 = 3a034c00 69006e00 75007800 20003300 2e003400 2e003400 2b002000 77006900 f2eeba00 3086584905 S Co:1:011:0 s 00 09 0001 0 f2eeba00 3086585055 C Co:1:011:0 0 0
Re: Linux USB file storage gadget with new UDC
On Mon, 24 Jun 2013, victor yeo wrote: Hi, Ok, is the usb_ep_set_wedge routine not working? I can't see that in the log file. It is not working. This can be seen in the usbmon log. I re-attach the usbmon log. If possible, please show me which line indicates that usb_ep_set_wedge routine is not working, or how to look for the clue. Is it from the control transfer line? Here's an example: f4148f80 308532 S Bo:1:011:1 -115 31 = 55534243 0600 c000 861a 003f00c0 00 f4148f80 308652 C Bo:1:011:1 0 31 f14c5600 308676 S Bi:1:011:1 -115 192 f14c5600 3087787651 C Bi:1:011:1 -121 16 = 0f00 080a0400 f4148f80 3087787674 S Bi:1:011:1 -115 13 f4148f80 3087803018 C Bi:1:011:1 0 13 = 55534253 0600 b000 00 The last line should have failed with a -32 error code, because the IN endpoint is supposed to be halted at this point. I think the GET_STATUS request is not handled by the gadget driver. Isn't it so? That's right. Get-Status, Set-Feature, and Clear-Feature requests must be handled by the UDC driver. Alan Stern Should the UDC driver handle Get-Status before or after the call to fsg_setup()? For these requests, the UDC driver should not call fsg_setup() at all. It should handle the request entirely by itself. 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
Re: Linux USB file storage gadget with new UDC
Hi, Yes, i see the bad characters in the log file. I apologize for that, my eyes was in pain after looking thru the log files and did not notice that when i attached the log file. The good news is i can get gadget to work with Lenovo x100e on Ubuntu and Windows. The change is adding more delay after writing to endpoint one IN FIFO register, for the case of writing more than the endpoint buffer size. However, the gadget only work on high-speed mode. If i disable ehci_hcd driver in Ubuntu (force it to be full speed), the same problem of SCSI_READ_10 command asking 4096 bytes and gadget returning the data, and gadget reset, still happens. I can bring up the gadget in full speed mode now, so the SCSI_READ_10 command problem is fixed. It is caused by an error interfacing to hardware. Now there is another problem with SCSI_MODE_SELECT_6 command, when in full speed mode, the data for SCSI_MODE_SELECT_6 command is 72 byte, and somehow the gadget is reset. Is it because gadget is not able to handle the amount of data? Please see the attached gadget log. Normally, in high speed mode, the data of SCSI_MODE_SELECT_6 command is 24 byte. Thanks, victor g_file_storage gadget: reset config g_file_storage gadget: reset interface g_file_storage gadget: in handle_exception loop g_file_storage gadget: in fsg-running loop g_file_storage gadget: in fsg-running loop g_file_storage gadget: ep0-setup, length 8: : 80 06 00 01 00 00 40 00 g_file_storage gadget: get device descriptor ept0 in queue len 0x12, buffer 0xc128f800 ep0_complete g_file_storage gadget: ep0-in, length 18: : 12 01 00 02 00 00 00 40 25 05 a5 a4 33 03 01 02 0010: 00 01 g_file_storage gadget: disconnect or port reset handle_exception begin handle_exception wait until handle_exception old_state 5 g_file_storage gadget: in handle_exception loop g_file_storage gadget: in fsg-running loop USB_RECIP_DEVICE fa is 0x3 exit A g_file_storage gadget: ep0-setup, length 8: : 80 06 00 01 00 00 12 00 g_file_storage gadget: get device descriptor exit C ept0 in queue len 0x12, buffer 0xc128f800 ep0_complete g_file_storage gadget: ep0-in, length 18: : 12 01 00 02 00 00 00 40 25 05 a5 a4 33 03 01 02 0010: 00 01 g_file_storage gadget: ep0-setup, length 8: : 80 06 00 02 00 00 09 00 g_file_storage gadget: get configuration descriptor ept0 in queue len 0x9, buffer 0xc128f800 ep0_complete g_file_storage gadget: ep0-in, length 9: : 09 02 20 00 01 01 04 c0 01 g_file_storage gadget: ep0-setup, length 8: : 00 09 01 00 00 00 00 00 g_file_storage gadget: set configuration handle_exception begin handle_exception wait until handle_exception old_state 4 g_file_storage gadget: set interface 0 g_file_storage gadget: full-speed config #1 EP1 OUT IRQ 0x28 ept0 in queue len 0x0, buffer 0xc128f800 g_file_storage gadget: in handle_exception loop [start_transfer] 800 0 ept1 out queue len 0x40, buffer 0xc134 before kagen2_ep_queue after kagen2_ep_queue kagen2_ep_queue 31 64 31 EP1 OUT IRQ 0x28 [kagen2_ep_queue] 43425355 87a68008 g_file_storage gadget: bulk-out, length 31: : 55 53 42 43 08 80 a6 87 18 00 00 00 00 00 06 15 0010: 10 00 00 18 00 00 00 00 00 00 00 00 00 00 00 g_file_storage gadget: SCSI command: MODE SELECT(6); Dc=6, Do=24; Hc=6, Ho=24 attention condition [start_transfer] 43425355 87a68008 ept1 out queue len 0x40, buffer 0xc134 before kagen2_ep_queue after kagen2_ep_queue kagen2_ep_queue 24 64 24 before kagen2_ep_queue g_file_storage gadget: disconnect or port reset after kagen2_ep_queue kagen2_ep_queue 48 64 24 before kagen2_ep_queue after kagen2_ep_queue kagen2_ep_queue 72 64 24 [kagen2_ep_queue] 800 0 g_file_storage gadget: bulk-out, length 72: : 00 00 00 08 00 00 00 00 00 00 02 00 08 0a 00 00 0010: ff ff 00 00 ff ff ff ff 00 00 00 00 00 00 00 5f 0020: c1 9f 75 00 58 1d 00 00 00 00 00 00 02 00 00 00 0030: 01 00 06 00 00 00 00 00 00 00 00 00 00 00 00 00 0040: 80 00 29 5f 22 e8 c2 4e g_file_storage gadget: bulk_out_complete -- 0, 72/24 g_file_storage gadget: before calling send_status g_file_storage gadget: sending command-failure status g_file_storage gadget: sense data: SK x06, ASC x29, ASCQ x00; info x0 g_file_storage gadget: bulk-in, length 13: : 55 53 42 53 08 80 a6 87 18 00 00 00 01 [start_transfer] 53425355 87a68008 exit C ept1 in queue len 0xd, buffer 0xc135 0: 0x53425355 4: 0x87a68008 8: 0x18 bulk_in_complete -- 0, 13/13 handle_exception begin handle_exception wait until handle_exception old_state 5 g_file_storage gadget: reset config g_file_storage gadget: reset interface g_file_storage gadget: in handle_exception loop g_file_storage gadget: in fsg-running loop g_file_storage gadget: in fsg-running loop g_file_storage gadget: ep0-setup, length 8: : 80 06 00 01 00 00 40 00 g_file_storage gadget: get device descriptor ept0 in queue len 0x12, buffer 0xc128f800 ep0_complete g_file_storage gadget: ep0-in, length 18: : 12 01
Re: Linux USB file storage gadget with new UDC
On Thu, 20 Jun 2013, victor yeo wrote: The problem is in UDC driver. i made the change, it is ok now. Good. I noticed that the usb_ep_set_wedge routine still isn't working right. You might try to fix that. 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
Re: Linux USB file storage gadget with new UDC
Hi, There is a mistake in the previous log file, because the fifo size is still set to 512 byte. Now i change it to 64 byte if it is Full speed. The FIFO size should always be set to the value in the endpoint descriptor, no matter what speed the connection is. The log file are attached. The log shows that your 64-byte transfers don't work very well. The first one didn't send any bytes. The second one sent only 4 bytes. And each of the ones after that sent 0 bytes. Alan Stern PS: Something was very wrong with the log file you posted. It is full of bad characters. You can it here: Yes, i see the bad characters in the log file. I apologize for that, my eyes was in pain after looking thru the log files and did not notice that when i attached the log file. The good news is i can get gadget to work with Lenovo x100e on Ubuntu and Windows. The change is adding more delay after writing to endpoint one IN FIFO register, for the case of writing more than the endpoint buffer size. However, the gadget only work on high-speed mode. If i disable ehci_hcd driver in Ubuntu (force it to be full speed), the same problem of SCSI_READ_10 command asking 4096 bytes and gadget returning the data, and gadget reset, still happens. Thanks, victor -- 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
Re: Linux USB file storage gadget with new UDC
Hi, I did another usbmon capture from the moment usb cable is plugged into the Ubuntu x100e laptop. This time the usbmon does not have -75 error. When the SCSI_READ_10 command request for 4096 bytes of data, and the data is returned by the gadget, usbmon simply shows -108 error. The gadget driver log and usbmon trace are attached. Again, the -108 indicates that the host controller disabled the port. The usbmon trace confirms this. I think the most common reason for disabling a port in this way is that the device tried to transmit a packet across a microframe boundary. The FIFO size in gadget bulk out endpoint 1 is 512 bytes, so i break the 4096 bytes of data into 8 chunks of 512 bytes, before returning them to Ubuntu. I guess it would not be the root cause, won't it? It's hard to say without looking at the signals on the wire. Are you certain the hardware really is sending 512 bytes for each chunk? That's why you need to use a bus analyzer -- to see what's actually going on. I have an important finding. When the problem (SCSI_READ_10 command reads 4096 bytes of data, causing gadget to reset) happens, the PC shows that the gadget is detected as Full-speed device, but gadget reports that it is set to High-speed from: g_file_storage gadget: high-speed config #1 This is printed from do_set_config() in file_storage.c. In UDC driver, it is hardcorded to high speed in UDC driver start function. I changed it to be set depending on hardware value. Now it is: g_file_storage gadget: full-speed config #1 However, in usbmon, the SCSI_READ_10 command still requests for 4096 bytes of data, and this causes gadget to reset. Please see the gadget log, and usbmon trace, and host dmesg log. Thanks, Victor [ 3427.328908] usb 1-5.2: new full speed USB device using ehci_hcd and address 7 [ 3427.421804] usb 1-5.2: not running at top speed; connect to a high speed hub [ 3427.455274] usb-storage 1-5.2:1.0: Quirks match for vid 0525 pid a4a5: 1 [ 3427.457117] scsi3 : usb-storage 1-5.2:1.0 [ 3428.896784] usb 1-5.2: reset full speed USB device using ehci_hcd and address 7 f33fa400 1314593130 C Ci:1:007:0 0 9 = 09022000 010104c0 01 f33fa400 1314593147 S Ci:1:007:0 s 80 06 0200 0020 32 f33fa400 1314593752 C Ci:1:007:0 0 32 = 09022000 010104c0 01090400 00020806 50050705 81024000 00070501 0240 f33fa400 1314593791 S Ci:1:007:0 s 80 06 0300 00ff 255 f33fa400 1314594502 C Ci:1:007:0 0 4 = 04030904 f33fa400 1314594519 S Ci:1:007:0 s 80 06 0302 0409 00ff 255 f33fa400 1314595120 C Ci:1:007:0 0 54 = 36034600 69006c00 65002d00 62006100 63006b00 65006400 20005300 74006f00 f33fa400 1314595918 S Ci:1:007:0 s 80 06 0301 0409 00ff 255 f33fa400 1314596884 C Ci:1:007:0 0 58 = 3a034c00 69006e00 75007800 20003300 2e003400 2e003400 2b002000 77006900 f33fa400 1314597660 S Co:1:007:0 s 00 09 0001 0 f33fa400 1314598122 C Co:1:007:0 0 0 f33fa400 1314599768 S Ci:1:007:0 s 80 06 0304 0409 00ff 255 f33fa400 1314612251 C Ci:1:007:0 0 26 = 1a035300 65006c00 66002d00 70006f00 77006500 72006500 6400 f2e1ee00 1314612435 S Ci:1:007:0 s 80 06 0305 0409 00ff 255 f2e1ee00 1314613115 C Ci:1:007:0 0 26 = 1a034d00 61007300 73002000 53007400 6f007200 61006700 6500 f33a1380 1315254841 S Co:1:003:0 s 23 03 0016 0302 0 f33a1380 1315255168 C Co:1:003:0 0 0 f2e1e400 1315646807 S Ci:1:007:0 s a1 fe 0001 1 f2e1e400 1315647355 C Ci:1:007:0 0 1 = 00 f2e1e400 1315655086 S Bo:1:007:1 -115 31 = 55534243 0100 2400 8612 0024 00 f2e1e400 1315655351 C Bo:1:007:1 0 31 f2ed1a00 1315655414 S Bi:1:007:1 -115 36 f2ed1a00 1315657108 C Bi:1:007:1 0 36 = 0202 1f00 4c696e75 78202020 46696c65 2d53746f 72204761 64676574 f2e1e400 1315657185 S Bi:1:007:1 -115 13 f2e1e400 1315666355 C Bi:1:007:1 0 13 = 55534253 0100 00 f2e1e400 1315708514 S Bo:1:007:1 -115 31 = 55534243 0200 0600 00 f2e1e400 1315708845 C Bo:1:007:1 0 31 f2e1e400 1315708919 S Bi:1:007:1 -115 13 f2e1e400 1315718221 C Bi:1:007:1 0 13 = 55534253 0200 01 f2e1e400 1315718323 S Bo:1:007:1 -115 31 = 55534243 0300 1200 8603 0012 00 f2e1e400 1315718460 C Bo:1:007:1 0 31 f2ed1700 1315718501 S Bi:1:007:1 -115 18 f2ed1700 1315728467 C Bi:1:007:1 0 18 = 7600 000a 2900 f2e1e400 1315728630 S Bi:1:007:1 -115 13 f2e1e400 1315737728 C Bi:1:007:1 0 13 = 55534253 0300 00 f2e1e400 1315738087 S Bo:1:007:1 -115 31 = 55534243 0400 0600 00 f2e1e400 1315738959 C Bo:1:007:1 0 31 f2e1e400 1315739098 S Bi:1:007:1 -115 13 f2e1e400 1315748116 C Bi:1:007:1 0 13 = 55534253 0400 00 f2e1e400 1315748392 S Bo:1:007:1 -115 31 = 55534243 0500 0800 8a25 00 f2e1e400 1315748596 C Bo:1:007:1 0 31 f33faa00 1315748619 S Bi:1:007:1 -115 8 f33faa00 1315758231 C Bi:1:007:1 0 8 =
Re: Linux USB file storage gadget with new UDC
On Mon, 17 Jun 2013, victor yeo wrote: I have an important finding. When the problem (SCSI_READ_10 command reads 4096 bytes of data, causing gadget to reset) happens, the PC shows that the gadget is detected as Full-speed device, but gadget reports that it is set to High-speed from: g_file_storage gadget: high-speed config #1 This is printed from do_set_config() in file_storage.c. In UDC driver, it is hardcorded to high speed in UDC driver start function. I changed it to be set depending on hardware value. Now it is: g_file_storage gadget: full-speed config #1 Yes, I remember mentioning this to you some time ago. However, in usbmon, the SCSI_READ_10 command still requests for 4096 bytes of data, and this causes gadget to reset. Please see the gadget log, and usbmon trace, and host dmesg log. There is a mistake in the previous log file, because the fifo size is still set to 512 byte. Now i change it to 64 byte if it is Full speed. The FIFO size should always be set to the value in the endpoint descriptor, no matter what speed the connection is. The log file are attached. The log shows that your 64-byte transfers don't work very well. The first one didn't send any bytes. The second one sent only 4 bytes. And each of the ones after that sent 0 bytes. Alan Stern PS: Something was very wrong with the log file you posted. It is full of bad characters. You can it here: http://marc.info/?l=linux-usbm=137145486920691w=2 -- 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
Re: Linux USB file storage gadget with new UDC
Hi, The usbmon trace shows lots of errors. All those -75 (EOVERFLOW) status codes mean that the gadget sent a packet that was too large, i.e., more than 512 bytes. This happened in all the READ(10) commands except the last one -- none of them succeeded in transferring any data. After the last READ(10) command was sent, the usbmon trace shows that the host's USB port got disabled. Maybe because of the too-long packets. Whatever the reason, that's why the ESHUTDOWN error occurred. The gadget's log does indeed show that the last READ(10) was received twice. The second time is a bug in the UDC driver. No command was sent by the host, so the driver should not have reported that a command was received. Alan Stern I did another usbmon capture from the moment usb cable is plugged into the Ubuntu x100e laptop. This time the usbmon does not have -75 error. When the SCSI_READ_10 command request for 4096 bytes of data, and the data is returned by the gadget, usbmon simply shows -108 error. The gadget driver log and usbmon trace are attached. The FIFO size in gadget bulk out endpoint 1 is 512 bytes, so i break the 4096 bytes of data into 8 chunks of 512 bytes, before returning them to Ubuntu. I guess it would not be the root cause, won't it? thanks, victor # dmesg -c g_file_storage gadget: disconnect or port reset handle_exception begin handle_exception wait until handle_exception old_state 5 g_file_storage gadget: in handle_exception loop g_file_storage gadget: in fsg-running loop g_file_storage gadget: disconnect or port reset handle_exception begin handle_exception wait until handle_exception old_state 5 g_file_storage gadget: in handle_exception loop g_file_storage gadget: in fsg-running loop g_file_storage gadget: ep0-setup, length 8: : 80 06 00 01 00 00 40 00 g_file_storage gadget: get device descriptor ept0 in queue len 0x12, buffer 0xc128f800 ep0_complete g_file_storage gadget: ep0-in, length 18: : 12 01 00 02 00 00 00 40 25 05 a5 a4 33 03 01 02 0010: 00 01 g_file_storage gadget: disconnect or port reset handle_exception begin handle_exception wait until handle_exception old_state 5 g_file_storage gadget: in handle_exception loop g_file_storage gadget: in fsg-running loop USB_RECIP_DEVICE fa is 0x2 exit A g_file_storage gadget: ep0-setup, length 8: : 80 06 00 01 00 00 12 00 g_file_storage gadget: get device descriptor ept0 in queue len 0x12, buffer 0xc128f800 ep0_complete g_file_storage gadget: ep0-in, length 18: : 12 01 00 02 00 00 00 40 25 05 a5 a4 33 03 01 02 0010: 00 01 g_file_storage gadget: ep0-setup, length 8: : 80 06 00 06 00 00 0a 00 g_file_storage gadget: get device qualifier ept0 in queue len 0xa, buffer 0xc128f800 ep0_complete g_file_storage gadget: ep0-in, length 10: : 0a 06 00 02 00 00 00 40 01 00 g_file_storage gadget: ep0-setup, length 8: : 80 06 00 02 00 00 09 00 g_file_storage gadget: get configuration descriptor ept0 in queue len 0x9, buffer 0xc128f800 ep0_complete g_file_storage gadget: ep0-in, length 9: : 09 02 20 00 01 01 04 c0 01 g_file_storage gadget: ep0-setup, length 8: : 80 06 00 02 00 00 20 00 g_file_storage gadget: get configuration descriptor ept0 in queue len 0x20, buffer 0xc128f800 ep0_complete g_file_storage gadget: ep0-in, length 32: : 09 02 20 00 01 01 04 c0 01 09 04 00 00 02 08 06 0010: 50 05 07 05 81 02 00 02 00 07 05 01 02 00 02 01 g_file_storage gadget: ep0-setup, length 8: : 80 06 00 03 00 00 ff 00 g_file_storage gadget: get string descriptor ept0 in queue len 0x4, buffer 0xc128f800 ep0_complete g_file_storage gadget: ep0-in, length 4: : 04 03 09 04 g_file_storage gadget: ep0-setup, length 8: : 80 06 02 03 09 04 ff 00 g_file_storage gadget: get string descriptor ept0 in queue len 0x36, buffer 0xc128f800 ep0_complete g_file_storage gadget: ep0-in, length 54: : 36 03 46 00 69 00 6c 00 65 00 2d 00 62 00 61 00 0010: 63 00 6b 00 65 00 64 00 20 00 53 00 74 00 6f 00 0020: 72 00 61 00 67 00 65 00 20 00 47 00 61 00 64 00 0030: 67 00 65 00 74 00 g_file_storage gadget: ep0-setup, length 8: : 80 06 01 03 09 04 ff 00 g_file_storage gadget: get string descriptor ept0 in queue len 0x3a, buffer 0xc128f800 ep0_complete g_file_storage gadget: ep0-in, length 58: : 3a 03 4c 00 69 00 6e 00 75 00 78 00 20 00 33 00 0010: 2e 00 34 00 2e 00 34 00 2b 00 20 00 77 00 69 00 0020: 74 00 68 00 20 00 6b 00 61 00 67 00 65 00 6e 00 0030: 32 00 5f 00 75 00 73 00 62 00 g_file_storage gadget: ep0-setup, length 8: : 00 09 01 00 00 00 00 00 g_file_storage gadget: set configuration handle_exception begin handle_exception wait until handle_exception old_state 4 g_file_storage gadget: set interface 0 g_file_storage gadget: high-speed config #1 g_file_storage gadget: ep0-setup, length 8: : 80 06 04 03 09 04 ff 00 g_file_storage gadget: get string descriptor ept0 in queue len 0x1a, buffer 0xc128f800 ep0_complete
Re: Linux USB file storage gadget with new UDC
On Wed, 12 Jun 2013, victor yeo wrote: I did another usbmon capture from the moment usb cable is plugged into the Ubuntu x100e laptop. This time the usbmon does not have -75 error. When the SCSI_READ_10 command request for 4096 bytes of data, and the data is returned by the gadget, usbmon simply shows -108 error. The gadget driver log and usbmon trace are attached. Again, the -108 indicates that the host controller disabled the port. The usbmon trace confirms this. I think the most common reason for disabling a port in this way is that the device tried to transmit a packet across a microframe boundary. The FIFO size in gadget bulk out endpoint 1 is 512 bytes, so i break the 4096 bytes of data into 8 chunks of 512 bytes, before returning them to Ubuntu. I guess it would not be the root cause, won't it? It's hard to say without looking at the signals on the wire. Are you certain the hardware really is sending 512 bytes for each chunk? That's why you need to use a bus analyzer -- to see what's actually going on. 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
Re: Linux USB file storage gadget with new UDC
Hi, The hardware handles Set Address request, and i can see the address of the USB gadget being shown in Windows host. Here i attach the gadget driver log for the Device Descriptor Test - Addressed State. The test just failed after Get Configuration request. I can't tell what's wrong. You will have to use a USB bus analyzer. Ok. Today i tested the same mass storage gadget driver on Lenovo x100e Ubuntu. There is a strange problem. After SCSI_READ_10 command data is returned to the Ubuntu host. The gadget driver says: g_file_storage gadget: reset config g_file_storage gadget: reset interface Then the same process to get descriptors and receive SCSI commands are repeated. Is the SCSI_READ_10 command or something else causing the problem? Please see the attached gadget driver log. Thanks, Victor [start_transfer] 0 0 ept1 out queue len 0x200, buffer 0xc134 before kagen2_ep_queue after kagen2_ep_queue kagen2_ep_queue 31 512 31 [kagen2_ep_queue] 43425355 12 g_file_storage gadget: bulk-out, length 31: : 55 53 42 43 12 00 00 00 00 10 00 00 80 00 0a 28 0010: 00 00 00 00 00 00 00 08 00 00 00 00 00 00 00 g_file_storage gadget: SCSI command: READ(10); Dc=10, Di=4096; Hc=10, Hi=4096 g_file_storage gadget-lun0: file read 4096 @ 0 - 4096 [start_transfer] 0 0 ept1 in queue len 0x1000, buffer 0xc134 len_num 4096, iter_num 0 0: 0x0 4: 0x0 8: 0x0 c: 0x0 len_num 3584, iter_num 1 0: 0x6d903ceb 4: 0x736f646b 8: 0x7366 c: 0x10402 len_num 3072, iter_num 2 0: 0xf8 4: 0xfff0 8: 0x0 c: 0x0 len_num 2560, iter_num 3 0: 0x0 4: 0x0 8: 0x0 c: 0x0 len_num 2048, iter_num 4 0: 0xf8 4: 0xfff0 8: 0x0 c: 0x0 len_num 1536, iter_num 5 0: 0x0 4: 0x0 8: 0x0 c: 0x0 len_num 1024, iter_num 6 0: 0x6f007442 4: 0x7000 8: 0xf00 c: 0xc100 len_num 512, iter_num 7 0: 0x0 4: 0x0 8: 0x0 c: 0x0 bulk_in_complete -- 0, 4096/4096 g_file_storage gadget: before calling send_status g_file_storage gadget: bulk-in, length 13: : 55 53 42 53 12 00 00 00 00 00 00 00 00 [start_transfer] 53425355 12 ept1 in queue len 0xd, buffer 0xc0c5c000 0: 0x53425355 4: 0x12 8: 0x0 bulk_in_complete -- 0, 13/13 [start_transfer] 0 0 ept1 out queue len 0x200, buffer 0xc134 before kagen2_ep_queue g_file_storage gadget: disconnect or port reset after kagen2_ep_queue kagen2_ep_queue 31 512 31 [kagen2_ep_queue] 43425355 12 g_file_storage gadget: bulk-out, length 31: : 55 53 42 43 12 00 00 00 00 10 00 00 80 00 0a 28 0010: 00 00 00 00 00 00 00 08 00 00 00 00 00 00 00 g_file_storage gadget: SCSI command: READ(10); Dc=10, Di=4096; Hc=10, Hi=4096 g_file_storage gadget-lun0: file read 4096 @ 0 - 4096 g_file_storage gadget: after calling do_scsi_command handle_exception begin handle_exception wait until handle_exception old_state 5 g_file_storage gadget: reset config g_file_storage gadget: reset interface g_file_storage gadget: in handle_exception loop g_file_storage gadget: in fsg-running loop g_file_storage gadget: in fsg-running loop g_file_storage gadget: ep0-setup, length 8: : 80 06 00 01 00 00 40 00 g_file_storage gadget: get device descriptor ept0 in queue len 0x12, buffer 0xc128b800 ep0_complete g_file_storage gadget: ep0-in, length 18: : 12 01 00 02 00 00 00 40 25 05 a5 a4 33 03 01 02 0010: 00 01 g_file_storage gadget: disconnect or port reset handle_exception begin handle_exception wait until handle_exception old_state 5 g_file_storage gadget: in handle_exception loop g_file_storage gadget: in fsg-running loop USB_RECIP_DEVICE function address is 0x5d exit A g_file_storage gadget: ep0-setup, length 8: : 80 06 00 01 00 00 12 00 g_file_storage gadget: get device descriptor ept0 in queue len 0x12, buffer 0xc128b800 ep0_complete g_file_storage gadget: ep0-in, length 18: : 12 01 00 02 00 00 00 40 25 05 a5 a4 33 03 01 02 0010: 00 01 g_file_storage gadget: ep0-setup, length 8: : 80 06 00 06 00 00 0a 00 g_file_storage gadget: get device qualifier ept0 in queue len 0xa, buffer 0xc128b800 ep0_complete g_file_storage gadget: ep0-in, length 10: : 0a 06 00 02 00 00 00 40 01 00 g_file_storage gadget: ep0-setup, length 8: : 80 06 00 02 00 00 09 00 g_file_storage gadget: get configuration descriptor ept0 in queue len 0x9, buffer 0xc128b800 ep0_complete g_file_storage gadget: ep0-in, length 9: : 09 02 20 00 01 01 04 c0 01 g_file_storage gadget: ep0-setup, length 8: : 80 06 00 02 00 00 20 00 g_file_storage gadget: get configuration descriptor ept0 in queue len 0x20, buffer 0xc128b800 ep0_complete g_file_storage gadget: ep0-in, length 32: : 09 02 20 00 01 01 04 c0 01 09 04 00 00 02 08 06 0010: 50 05 07 05 81 02 00 02 00 07 05 01 02 00 02 01 g_file_storage gadget: ep0-setup, length 8: : 80 06 00 03 00 00 ff 00 g_file_storage gadget: get string descriptor ept0 in queue len 0x4, buffer 0xc128b800 ep0_complete g_file_storage gadget: ep0-in, length 4: : 04 03 09 04 g_file_storage gadget: ep0-setup,
Re: Linux USB file storage gadget with new UDC
On Tue, 11 Jun 2013, victor yeo wrote: Hi, The hardware handles Set Address request, and i can see the address of the USB gadget being shown in Windows host. Here i attach the gadget driver log for the Device Descriptor Test - Addressed State. The test just failed after Get Configuration request. I can't tell what's wrong. You will have to use a USB bus analyzer. Another possibility is to set up a virtual Windows system inside your Linux host. Then try running the USB CV program on the virtual machine, and use usbmon on the host system to capture the USB traffic. I don't know if that will work, but it might. Ok. Today i tested the same mass storage gadget driver on Lenovo x100e Ubuntu. There is a strange problem. After SCSI_READ_10 command data is returned to the Ubuntu host. The gadget driver says: g_file_storage gadget: reset config g_file_storage gadget: reset interface Then the same process to get descriptors and receive SCSI commands are repeated. Is the SCSI_READ_10 command or something else causing the problem? Please see the attached gadget driver log. Perhaps you will recognize this answer (I have sent it several times before): I can't tell what is happening without seeing _both_ the log file on the gadget _and_ the usbmon trace on the host. 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
Re: Linux USB file storage gadget with new UDC
Hi, Another possibility is to set up a virtual Windows system inside your Linux host. Then try running the USB CV program on the virtual machine, and use usbmon on the host system to capture the USB traffic. I don't know if that will work, but it might. Thanks. i will find a way to setup the virtual Windows inside Linux host. Ok. Today i tested the same mass storage gadget driver on Lenovo x100e Ubuntu. There is a strange problem. After SCSI_READ_10 command data is returned to the Ubuntu host. The gadget driver says: g_file_storage gadget: reset config g_file_storage gadget: reset interface Then the same process to get descriptors and receive SCSI commands are repeated. Is the SCSI_READ_10 command or something else causing the problem? Please see the attached gadget driver log. Perhaps you will recognize this answer (I have sent it several times before): I can't tell what is happening without seeing _both_ the log file on the gadget _and_ the usbmon trace on the host. Alan Stern Yes, the matching gadget log and usbmon trace are attached in this email. From the usbmon trace, the error (-108) is ESHUTDOWN from SCSI_READ_10 command. From the gadget log, the last SCSI_READ_10 command is received twice. First time it is ok, second time it causes some problem. Which side could cause the ESHUTDOWN error? Thanks, victor [start_transfer] 43425355 35 ept1 out queue len 0x200, buffer 0xc0c44000 before kagen2_ep_queue after kagen2_ep_queue kagen2_ep_queue 31 512 31 [kagen2_ep_queue] 43425355 36 g_file_storage gadget: bulk-out, length 31: : 55 53 42 43 36 00 00 00 12 00 00 00 80 00 06 03 0010: 00 00 00 12 00 00 00 00 00 00 00 00 00 00 00 g_file_storage gadget: SCSI command: REQUEST SENSE; Dc=6, Di=18; Hc=6, Hi=18 g_file_storage gadget: bulk-in, length 18: : 70 00 06 00 00 00 00 0a 00 00 00 00 29 00 00 00 0010: 00 00 [start_transfer] 60070 a00 ept1 in queue len 0x12, buffer 0xc0c44000 0: 0x60070 4: 0xa00 8: 0x0 c: 0x29 bulk_in_complete -- 0, 18/18 g_file_storage gadget: before calling send_status g_file_storage gadget: bulk-in, length 13: : 55 53 42 53 36 00 00 00 00 00 00 00 00 [start_transfer] 53425355 36 ept1 in queue len 0xd, buffer 0xc1338000 0: 0x53425355 4: 0x36 8: 0x0 bulk_in_complete -- 0, 13/13 [start_transfer] 60070 a00 ept1 out queue len 0x200, buffer 0xc0c44000 before kagen2_ep_queue after kagen2_ep_queue kagen2_ep_queue 31 512 31 [kagen2_ep_queue] 43425355 37 g_file_storage gadget: bulk-out, length 31: : 55 53 42 43 37 00 00 00 00 10 00 00 80 00 0a 28 0010: 00 00 00 00 18 00 00 08 00 00 00 00 00 00 00 g_file_storage gadget: SCSI command: READ(10); Dc=10, Di=4096; Hc=10, Hi=4096 g_file_storage gadget-lun0: file read 4096 @ 12288 - 4096 [start_transfer] 0 0 ept1 in queue len 0x1000, buffer 0xc0c44000 len_num 4096, iter_num 0 0: 0x0 4: 0x0 8: 0x0 c: 0x0 len_num 3584, iter_num 1 0: 0x0 4: 0x0 8: 0x0 c: 0x0 len_num 3072, iter_num 2 0: 0x0 4: 0x0 8: 0x0 c: 0x0 len_num 2560, iter_num 3 0: 0x0 4: 0x0 8: 0x0 c: 0x0 len_num 2048, iter_num 4 0: 0x0 4: 0x0 8: 0x0 c: 0x0 len_num 1536, iter_num 5 0: 0x0 4: 0x0 8: 0x0 c: 0x0 len_num 1024, iter_num 6 0: 0x0 4: 0x0 8: 0x0 c: 0x0 len_num 512, iter_num 7 0: 0x0 4: 0x0 8: 0x0 c: 0x0 bulk_in_complete -- 0, 4096/4096 g_file_storage gadget: before calling send_status g_file_storage gadget: bulk-in, length 13: : 55 53 42 53 37 00 00 00 00 00 00 00 00 [start_transfer] 53425355 37 ept1 in queue len 0xd, buffer 0xc1338000 0: 0x53425355 4: 0x37 8: 0x0 bulk_in_complete -- 0, 13/13 [start_transfer] 0 0 ept1 out queue len 0x200, buffer 0xc0c44000 before kagen2_ep_queue after kagen2_ep_queue kagen2_ep_queue 31 512 31 [kagen2_ep_queue] 43425355 38 g_file_storage gadget: bulk-out, length 31: : 55 53 42 43 38 00 00 00 00 10 00 00 80 00 0a 28 0010: 00 00 00 00 00 00 00 08 00 00 00 00 00 00 00 g_file_storage gadget: SCSI command: READ(10); Dc=10, Di=4096; Hc=10, Hi=4096 g_file_storage gadget-lun0: file read 4096 @ 0 - 4096 [start_transfer] 0 0 ept1 in queue len 0x1000, buffer 0xc0c44000 len_num 4096, iter_num 0 0: 0x0 4: 0x0 8: 0x0 c: 0x0 len_num 3584, iter_num 1 0: 0x6d903ceb 4: 0x736f646b 8: 0x7366 c: 0x10402 len_num 3072, iter_num 2 0: 0xf8 4: 0xfff0 8: 0x0 c: 0x0 len_num 2560, iter_num 3 0: 0x0 4: 0x0 8: 0x0 c: 0x0 len_num 2048, iter_num 4 0: 0xf8 4: 0xfff0 8: 0x0 c: 0x0 len_num 1536, iter_num 5 0: 0x0 4: 0x0 8: 0x0 c: 0x0 len_num 1024, iter_num 6 0: 0x6f007442 4: 0x7000 8: 0xf00 c: 0xc100 len_num 512, iter_num 7 0: 0x0 4: 0x0 8: 0x0 c: 0x0 bulk_in_complete -- 0, 4096/4096 g_file_storage gadget: before calling send_status g_file_storage gadget: bulk-in, length 13: : 55 53 42 53 38 00 00 00 00 00 00 00 00 [start_transfer] 53425355 38 ept1 in queue len 0xd, buffer 0xc1338000 0: 0x53425355 4: 0x38 8: 0x0 bulk_in_complete -- 0, 13/13 [start_transfer] 0 0 ept1 out queue len 0x200, buffer 0xc0c44000
Re: Linux USB file storage gadget with new UDC
On Tue, 11 Jun 2013, victor yeo wrote: Yes, the matching gadget log and usbmon trace are attached in this email. From the usbmon trace, the error (-108) is ESHUTDOWN from SCSI_READ_10 command. From the gadget log, the last SCSI_READ_10 command is received twice. First time it is ok, second time it causes some problem. Which side could cause the ESHUTDOWN error? The usbmon trace shows lots of errors. All those -75 (EOVERFLOW) status codes mean that the gadget sent a packet that was too large, i.e., more than 512 bytes. This happened in all the READ(10) commands except the last one -- none of them succeeded in transferring any data. After the last READ(10) command was sent, the usbmon trace shows that the host's USB port got disabled. Maybe because of the too-long packets. Whatever the reason, that's why the ESHUTDOWN error occurred. The gadget's log does indeed show that the last READ(10) was received twice. The second time is a bug in the UDC driver. No command was sent by the host, so the driver should not have reported that a command was received. 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
Re: Linux USB file storage gadget with new UDC
Hi, Thanks a lot. i understand this part now. Do you notice the Set Address request is not seen by the gadget driver? The Set Address request is handled by the hardware. Could it be the root cause? As gadget driver may expect the address information from the host, and for now UDC driver just ignore the Set Address request ? That may very well be related to the problem. Gadget drivers expect UDC drivers or UDC hardware to handle Set-Address requests automatically. If your UDC or driver doesn't handle them, it could cause a test to fail. The hardware handles Set Address request, and i can see the address of the USB gadget being shown in Windows host. Here i attach the gadget driver log for the Device Descriptor Test - Addressed State. The test just failed after Get Configuration request. Another question, in ep0_complete(): if (req-status == 0 req-context) ((fsg_routine_t) (req-context))(fsg); Is req-context pointing to a function in UDC driver? Thanks, victor # dmesg g_file_storage gadget: ep0-setup, length 8: : 80 06 00 01 00 00 12 00 g_file_storage gadget: get device descriptor ept0 in queue len 0x12, buffer 0xc1289800 ep0_complete g_file_storage gadget: ep0-in, length 18: : 12 01 00 02 00 00 00 40 25 05 a5 a4 33 03 01 02 0010: 00 01 g_file_storage gadget: ep0-setup, length 8: : 80 06 00 06 00 00 0a 00 g_file_storage gadget: get device qualifier ept0 in queue len 0xa, buffer 0xc1289800 ep0_complete g_file_storage gadget: ep0-in, length 10: : 0a 06 00 02 00 00 00 40 01 00 g_file_storage gadget: ep0-setup, length 8: : 80 06 00 02 00 00 09 00 g_file_storage gadget: get configuration descriptor ept0 in queue len 0x9, buffer 0xc1289800 ep0_complete g_file_storage gadget: ep0-in, length 9: : 09 02 20 00 01 01 04 c0 01 g_file_storage gadget: ep0-setup, length 8: : 80 08 00 00 00 00 01 00 g_file_storage gadget: get configuration ept0 in queue len 0x1, buffer 0xc1289800 ep0_complete g_file_storage gadget: ep0-in, length 1: : 01 g_file_storage gadget: ep0-setup, length 8: : 80 08 00 00 00 00 01 00 g_file_storage gadget: get configuration ept0 in queue len 0x1, buffer 0xc1289800 ep0_complete g_file_storage gadget: ep0-in, length 1: : 01 #
Re: Linux USB file storage gadget with new UDC
On Fri, 7 Jun 2013, victor yeo wrote: The hardware handles Set Address request, and i can see the address of the USB gadget being shown in Windows host. Here i attach the gadget driver log for the Device Descriptor Test - Addressed State. The test just failed after Get Configuration request. I can't tell what's wrong. You will have to use a USB bus analyzer. Another question, in ep0_complete(): if (req-status == 0 req-context) ((fsg_routine_t) (req-context))(fsg); Is req-context pointing to a function in UDC driver? No, it points to a function in g_file_storage. The context pointer gets set in only place, in class_setup_req(): fsg-ep0req-context = received_cbi_adsc; 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
Re: Linux USB file storage gadget with new UDC
Hi,
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.
Unfortunately, that USB 2.0 command verifier is not able to generate a
more verbose log.
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.
Thanks a lot. i understand this part now. Do you notice the Set
Address request is not seen by the gadget driver? The Set Address
request is handled by the hardware. Could it be the root cause? As
gadget driver may expect the address information from the host, and
for now UDC driver just ignore the Set Address request ?
victor
--
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
Re: Linux USB file storage gadget with new UDC
On Wed, 5 Jun 2013, victor yeo wrote: Thanks a lot. i understand this part now. Do you notice the Set Address request is not seen by the gadget driver? The Set Address request is handled by the hardware. Could it be the root cause? As gadget driver may expect the address information from the host, and for now UDC driver just ignore the Set Address request ? That may very well be related to the problem. Gadget drivers expect UDC drivers or UDC hardware to handle Set-Address requests automatically. If your UDC or driver doesn't handle them, it could cause a test to fail. 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
Re: Linux USB file storage gadget with new UDC
Hi, When i run USB 2.0 Command Verifier on file gadget and UDC driver, an error in Command Verifier says Device must support being set to Addressed/Configured state. Does it mean the gadget cannot support putting device in addressed state or configured state, as in supporting the Set Address and Set Configuration requests? I don't know what it means. The gadget _does_ support being set to the Addressed and Configured states. If it didn't support these things, you would not have been able to test it at all. Alan Stern The gadget log when Command Verifier says Device must support being set to Addressed/Configured state is attached. The log shows get device descriptor, get configuration descriptor, and set configuration requests are received. I see nothing wrong in gadget log. Does the log indicate any problem that corresponds to the error message in Command Verifier? Thanks, victor # dmesg g_file_storage gadget: disconnect or port reset after kagen2_ep_queue kagen2_ep_queue 31 512 31 [kagen2_ep_queue] 43425355 8a47aaf8 g_file_storage gadget: bulk-out, length 31: : 55 53 42 43 f8 aa 47 8a 00 00 00 00 00 00 0a 35 0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 g_file_storage gadget: SCSI command: SYNCHRONIZE CACHE; Dc=10, Dn=0; Hc=10, Hn=0 attention condition g_file_storage gadget: after calling do_scsi_command g_file_storage gadget: reset config g_file_storage gadget: reset interface g_file_storage gadget: in handle_exception loop g_file_storage gadget: in fsg-running loop g_file_storage gadget: in fsg-running loop g_file_storage gadget: disconnect or port reset g_file_storage gadget: in handle_exception loop g_file_storage gadget: in fsg-running loop g_file_storage gadget: ep0-setup, length 8: : 80 06 00 01 00 00 12 00 g_file_storage gadget: get device descriptor ept0 in queue len 0x12, buffer 0xc1289800 g_file_storage gadget: ep0-in, length 18: : 12 01 00 02 00 00 00 40 25 05 a5 a4 33 03 01 02 0010: 00 01 USB_RECIP_DEVICE g_file_storage gadget: ep0-setup, length 8: : 80 06 00 01 00 00 12 00 g_file_storage gadget: get device descriptor ept0 in queue len 0x12, buffer 0xc1289800 g_file_storage gadget: ep0-in, length 18: : 12 01 00 02 00 00 00 40 25 05 a5 a4 33 03 01 02 0010: 00 01 g_file_storage gadget: ep0-setup, length 8: : 80 06 00 02 00 00 09 00 g_file_storage gadget: get configuration descriptor ept0 in queue len 0x9, buffer 0xc1289800 g_file_storage gadget: ep0-in, length 9: : 09 02 20 00 01 01 04 c0 01 g_file_storage gadget: ep0-setup, length 8: : 00 09 01 00 00 00 00 00 g_file_storage gadget: set configuration g_file_storage gadget: set interface 0 g_file_storage gadget: high-speed config #1 g_file_storage gadget: ep0-setup, length 8: : 80 06 00 02 00 00 09 00 g_file_storage gadget: get configuration descriptor ept0 in queue len 0x9, buffer 0xc1289800 g_file_storage gadget: ep0-in, length 9: : 09 02 20 00 01 01 04 c0 01 g_file_storage gadget: ep0-setup, length 8: : 80 06 00 02 00 00 20 00 g_file_storage gadget: get configuration descriptor ept0 in queue len 0x20, buffer 0xc1289800 g_file_storage gadget: ep0-in, length 32: : 09 02 20 00 01 01 04 c0 01 09 04 00 00 02 08 06 0010: 50 05 07 05 81 02 00 02 00 07 05 01 02 00 02 01 g_file_storage gadget: in handle_exception loop [start_transfer] 43425355 8a47aaf8 ept1 out queue len 0x200, buffer 0xc0c44000 before kagen2_ep_queue g_file_storage gadget: ep0-setup, length 8: : 80 06 00 01 00 00 12 00 g_file_storage gadget: get device descriptor ept0 in queue len 0x12, buffer 0xc1289800 g_file_storage gadget: ep0-in, length 18: : 12 01 00 02 00 00 00 40 25 05 a5 a4 33 03 01 02 0010: 00 01 g_file_storage gadget: ep0-setup, length 8: : 80 06 00 06 00 00 0a 00 g_file_storage gadget: get device qualifier ept0 in queue len 0xa, buffer 0xc1289800 g_file_storage gadget: ep0-in, length 10: : 0a 06 00 02 00 00 00 40 01 00 g_file_storage gadget: ep0-setup, length 8: : 80 06 00 02 00 00 09 00 g_file_storage gadget: get configuration descriptor ept0 in queue len 0x9, buffer 0xc1289800 g_file_storage gadget: ep0-in, length 9: : 09 02 20 00 01 01 04 c0 01 g_file_storage gadget: ep0-setup, length 8: : 80 08 00 00 00 00 01 00 g_file_storage gadget: get configuration ept0 in queue len 0x1, buffer 0xc1289800 g_file_storage gadget: ep0-in, length 1: : 01 g_file_storage gadget: ep0-setup, length 8: : 80 08 00 00 00 00 01 00 g_file_storage gadget: get configuration ept0 in queue len 0x1, buffer 0xc1289800 g_file_storage gadget: ep0-in, length 1: : 01 #
Re: Linux USB file storage gadget with new UDC
On Mon, 3 Jun 2013, victor yeo wrote: The gadget log when Command Verifier says Device must support being set to Addressed/Configured state is attached. The log shows get device descriptor, get configuration descriptor, and set configuration requests are received. I see nothing wrong in gadget log. Does the log indicate any problem that corresponds to the error message in Command Verifier? I have no idea what the CV test is doing. If you can get a log from the CV program, that would help. There is one strange thing in the middle of the gadget log: g_file_storage gadget: ep0-setup, length 8: : 80 06 00 02 00 00 20 00 g_file_storage gadget: get configuration descriptor ept0 in queue len 0x20, buffer 0xc1289800 g_file_storage gadget: ep0-in, length 32: : 09 02 20 00 01 01 04 c0 01 09 04 00 00 02 08 06 0010: 50 05 07 05 81 02 00 02 00 07 05 01 02 00 02 01 g_file_storage gadget: in handle_exception loop [start_transfer] 43425355 8a47aaf8 ept1 out queue len 0x200, buffer 0xc0c44000 before kagen2_ep_queue g_file_storage gadget: ep0-setup, length 8: : 80 06 00 01 00 00 12 00 g_file_storage gadget: get device descriptor ept0 in queue len 0x12, buffer 0xc1289800 g_file_storage gadget: ep0-in, length 18: : 12 01 00 02 00 00 00 40 25 05 a5 a4 33 03 01 02 0010: 00 01 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. 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
Re: Linux USB file storage gadget with new UDC
Hi, On Thu, May 30, 2013 at 10:44 PM, Alan Stern st...@rowland.harvard.edu wrote: On Thu, 30 May 2013, victor yeo wrote: I tested the g_zero with USB 2.0 Command Verifier. After the Command Verifier is run, the UDC gadget driver queue function is continuously being called, and the linux command prompt is frozen. Please see the attached UDC driver log. It looks like endpoint 1 in direction is called by USB 2.0 Command Verifier continuously. Is this weird? I don't know. You can't tell what's going on just by looking at the gadget. You have to know what the host is doing as well. Alan Stern When i run USB 2.0 Command Verifier on file gadget and UDC driver, an error in Command Verifier says Device must support being set to Addressed/Configured state. Does it mean the gadget cannot support putting device in addressed state or configured state, as in supporting the Set Address and Set Configuration requests? Thanks, Victor -- 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
Re: Linux USB file storage gadget with new UDC
On Fri, 31 May 2013, victor yeo wrote: When i run USB 2.0 Command Verifier on file gadget and UDC driver, an error in Command Verifier says Device must support being set to Addressed/Configured state. Does it mean the gadget cannot support putting device in addressed state or configured state, as in supporting the Set Address and Set Configuration requests? I don't know what it means. The gadget _does_ support being set to the Addressed and Configured states. If it didn't support these things, you would not have been able to test it at all. 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
Re: Linux USB file storage gadget with new UDC
Hi, Ok. What other gadget driver can i test with UDC driver? Is it the mass storage driver (mass_storage.c)? That is essentially the same as g_file_storage. But there are lots of others. You should start with g_zero and run the testusb suite. See http://www.linux-usb.org/gadget/ and http://www.linux-usb.org/usbtest/ for more information. Those web pages are pretty old and somewhat out of date, but they still have useful stuff. I tested the g_zero with USB 2.0 Command Verifier. After the Command Verifier is run, the UDC gadget driver queue function is continuously being called, and the linux command prompt is frozen. Please see the attached UDC driver log. It looks like endpoint 1 in direction is called by USB 2.0 Command Verifier continuously. Is this weird? thanks, victor # insmod kagen2_udc.ko kagen2_init kagen2_plat_probe 1 kagen2_plat_probe 5 kagen2_plat_probe 6, 0xc2886000 0x1000 read pclk scu 7 irqmask ffbd 7fff val is 0x0 val is 0x8 check USB_OTGST 0x51000801 check USB_OTGIRQ 0x51000810 check USB_IRQINIT 0x70007 check USB_OTGFSM 0xa1d191f check USB_OTGCTRL 0x51300801 kagen2_plat_probe 8 register irq 32 kagen2_init 0 # insmod g_zero.ko bind epname ep1 epname ep1 epname ep1 epname ep1 gadget: Gadget Zero, version: Cinco de Mayo 2008 gadget: zero ready usb_gadget_udc_start 0xbf0386b8 0xbf0364c8 kagen2_start 0xbf0386b8 0xbf0364c8 0xc12d2cf0 0xbf030eb0 usb_gadget_connect # ept0 in queue len 0x12, buffer 0xc12d3000 USB_RECIP_DEVICE exit A ept0 in queue len 0x12, buffer 0xc12d3000 ept0 in queue len 0x9, buffer 0xc12d3000 ept0 in queue len 0x4, buffer 0xc12d3000 ept0 in queue len 0x42, buffer 0xc12d3000 ept0 in queue len 0x20, buffer 0xc12d3000 ept0 in queue len 0x4, buffer 0xc12d3000 ept0 in queue len 0x18, buffer 0xc12d3000 ept0 in queue len 0x4, buffer 0xc12d3000 ept0 in queue len 0x18, buffer 0xc12d3000 ept0 in queue len 0x20, buffer 0xc12d3000 ept0 in queue len 0xa, buffer 0xc12d3000 ept0 in queue len 0x9, buffer 0xc12d3000 ept0 in queue len 0x20, buffer 0xc12d3000 ept0 in queue len 0x4, buffer 0xc12d3000 ept0 in queue len 0x3a, buffer 0xc12d3000 ept0 in queue len 0x18, buffer 0xc12d3000 ept0 in queue len 0x42, buffer 0xc12d3000 ept0 in queue len 0x2a, buffer 0xc12d3000 ept0 in queue len 0x2a, buffer 0xc12d3000 ept0 in queue len 0x12, buffer 0xc12d3000 USB_RECIP_DEVICE exit A ept0 in queue len 0x12, buffer 0xc12d3000 ept0 in queue len 0x9, buffer 0xc12d3000 zero gadget: high-speed config #3: source/sink ept1 in queue len 0x1000, buffer 0xc180d000 len_num 4096, iter_num 0 len_num 3584, iter_num 1 len_num 3072, iter_num 2 len_num 2560, iter_num 3 len_num 2048, iter_num 4 len_num 1536, iter_num 5 len_num 1024, iter_num 6 len_num 512, iter_num 7 ept1 in queue len 0x1000, buffer 0xc180d000 len_num 4096, iter_num 0 len_num 3584, iter_num 1 len_num 3072, iter_num 2 len_num 2560, iter_num 3 len_num 2048, iter_num 4 len_num 1536, iter_num 5 len_num 1024, iter_num 6 len_num 512, iter_num 7 ept1 in queue len 0x1000, buffer 0xc180d000 len_num 4096, iter_num 0 len_num 3584, iter_num 1 len_num 3072, iter_num 2 len_num 2560, iter_num 3 len_num 2048, iter_num 4 len_num 1536, iter_num 5 len_num 1024, iter_num 6 len_num 512, iter_num 7 ept1 in queue len 0x1000, buffer 0xc180d000 len_num 4096, iter_num 0 len_num 3584, iter_num 1 len_num 3072, iter_num 2 len_num 2560, iter_num 3 len_num 2048, iter_num 4 len_num 1536, iter_num 5 len_num 1024, iter_num 6 len_num 512, iter_num 7 ept1 in queue len 0x1000, buffer 0xc180d000 len_num 4096, iter_num 0 len_num 3584, iter_num 1 len_num 3072, iter_num 2 len_num 2560, iter_num 3 len_num 2048, iter_num 4 len_num 1536, iter_num 5 len_num 1024, iter_num 6 len_num 512, iter_num 7 ept1 in queue len 0x1000, buffer 0xc180d000 len_num 4096, iter_num 0 len_num 3584, iter_num 1 len_num 3072, iter_num 2 len_num 2560, iter_num 3 len_num 2048, iter_num 4 len_num 1536, iter_num 5 len_num 1024, iter_num 6 len_num 512, iter_num 7 ept1 in queue len 0x1000, buffer 0xc180d000 len_num 4096, iter_num 0 len_num 3584, iter_num 1 len_num 3072, iter_num 2 len_num 2560, iter_num 3 len_num 2048, iter_num 4 len_num 1536, iter_num 5 len_num 1024, iter_num 6 len_num 512, iter_num 7 ept1 in queue len 0x1000, buffer 0xc180d000 len_num 4096, iter_num 0 len_num 3584, iter_num 1 len_num 3072, iter_num 2 len_num 2560, iter_num 3 len_num 2048, iter_num 4 len_num 1536, iter_num 5 len_num 1024, iter_num 6 len_num 512, iter_num 7 ept1 in queue len 0x1000, buffer 0xc180d000 len_num 4096, iter_num 0 len_num 3584, iter_num 1 len_num 3072, iter_num 2 len_num 2560, iter_num 3 len_num 2048, iter_num 4 len_num 1536, iter_num 5 len_num 1024, iter_num 6 len_num 512, iter_num 7
Re: Linux USB file storage gadget with new UDC
On Thu, 30 May 2013, victor yeo wrote: I tested the g_zero with USB 2.0 Command Verifier. After the Command Verifier is run, the UDC gadget driver queue function is continuously being called, and the linux command prompt is frozen. Please see the attached UDC driver log. It looks like endpoint 1 in direction is called by USB 2.0 Command Verifier continuously. Is this weird? I don't know. You can't tell what's going on just by looking at the gadget. You have to know what the host is doing as well. 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
Re: Linux USB file storage gadget with new UDC
Hi, Is it possible to contribute the code to Linux community? Yes. But first you should test it with other gadget drivers, not just g_file_storage. Ok. What other gadget driver can i test with UDC driver? Is it the mass storage driver (mass_storage.c)? Has the g_file_storage passed the USB 2.0 Command Verifier test? On the other hand, i run the USB 2.0 command verifier to test the gadget, the gadget crashes at BOS descriptor test. I think the gadget is not able to handle BOS descriptor, is the gadget driver setup function returning negative error code for BOS descriptor? The crash dump you attached contained this line: PC is at kagen2_irq+0x290/0x3bc [kagen2_udc] This means the crash occurred inside the UDC driver, not the gadget driver. Yes, the problem was solved just now. Thanks, victor -- 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
Re: Linux USB file storage gadget with new UDC
On Wed, 29 May 2013, victor yeo wrote: Hi, Is it possible to contribute the code to Linux community? Yes. But first you should test it with other gadget drivers, not just g_file_storage. Ok. What other gadget driver can i test with UDC driver? Is it the mass storage driver (mass_storage.c)? That is essentially the same as g_file_storage. But there are lots of others. You should start with g_zero and run the testusb suite. See http://www.linux-usb.org/gadget/ and http://www.linux-usb.org/usbtest/ for more information. Those web pages are pretty old and somewhat out of date, but they still have useful stuff. Has the g_file_storage passed the USB 2.0 Command Verifier test? I think so, but I haven't tested it myself. Of course, the result will vary depending on which UDC driver you test. 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
Re: Linux USB file storage gadget with new UDC
Hi, Yes, it is silly. The hardware interrupt is not being generated for every SCSI command received, so the driver has to poll. I put the polling code in a thread, and this dilemma is fixed. Are you sure about this? If it is correct, you should _fix_ the interrupt problem. Don't try to work around it by creating a new thread. Figure out why there isn't an interrupt. Does your driver forget to set an interrupt-enable bit? I still observe the SCSI_WRITE_10 command time out sometimes. When time out happens, the gadget log shows: g_file_storage gadget: invalid CBW: len 512 sig 0x6f007442 g_file_storage gadget: bulk-in set wedge Is it because the gadget expects 31 byte command, but 512 byte data is received instead? No. It is because kagen2_ep_queue returned _before_ a new command was received, probably as a result of your polling thread. Since there was no new command, the data in the buffer was wrong. The full UDC/gadget log is attached. Hope it is useful. If not, i will add in more printk statements. You can see the problem in the log: g_file_storage gadget: bulk-in, length 13: : 55 53 42 53 50 00 00 00 00 00 00 00 00 [start_transfer] 53425355 50 ept1 in queue len 0xd, buffer 0xc0c3c000 0: 0x53425355 4: 0x50 8: 0x0 bulk_in_complete -- 0, 13/13 That was the end of the previous command. Now the gadget waits for a new command to arrive. [start_transfer] 6f007442 7000 ept1 out queue len 0x200, buffer 0xc1338000 before kagen2_ep_queue after kagen2_ep_queue kagen2_ep_queue 512 512 512 [kagen2_ep_queue] 6f007442 7000 kagen2_ep_queue returned but there was no interrupt. This means no new data was received, so the old data is still in the buffer. g_file_storage gadget: bulk_out_complete -- 0, 512/31 g_file_storage gadget: invalid CBW: len 512 sig 0x6f007442 g_file_storage gadget: bulk-in set wedge That 0x6f007442 is the old data from the previous command, as you can see from the log messages (it is the same data that was present when kagen2_ep_queue was called). Now the UDC driver is working on both Linux and Windows host, meaning the read/write operation is ok. I still use the polling method, because waiting for interrupt is not reliable. Is it possible to contribute the code to Linux community? On the other hand, i run the USB 2.0 command verifier to test the gadget, the gadget crashes at BOS descriptor test. I think the gadget is not able to handle BOS descriptor, is the gadget driver setup function returning negative error code for BOS descriptor? Thanks, victor g_file_storage gadget: high-speed config #1 Unable to handle kernel NULL pointer dereference at virtual address pgd = c0204000 [] *pgd= Internal error: Oops - BUG: 817 [#1] PREEMPT ARM Modules linked in: g_file_storage kagen2_udc ath6kl_sdio ath6kl_core ka2000_sdio ka2000_sdhc CPU: 0Not tainted (3.4.4+ #43) PC is at kagen2_irq+0x290/0x3bc [kagen2_udc] LR is at handle_irq_event_percpu+0x30/0x178 pc : [bf02f704]lr : [c02496d0]psr: 6093 sp : c132de98 ip : 0002 fp : c132debc r10: r9 : r8 : r7 : 0020 r6 : 0002 r5 : 0201 r4 : c12a8c00 r3 : r2 : 0001 r1 : c12a8d1c r0 : Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 0005717f Table: 0130c000 DAC: 0017 Process chkbusy_t (pid: 121, stack limit = 0xc132c270) Stack: (0xc132de98 to 0xc132e000) de80: 0080 0002 dea0: c12b9840 c049cf70 0020 c132dee4 c132dec0 c02496d0 bf02f484 dec0: c049cf70 c132c000 c12b9840 c132df94 c132df04 c132dee8 dee0: c0249878 c02496b0 f5006000 c049cf70 f5006000 c132df1c c132df08 df00: c024bd38 c0249828 c024bc24 0020 c132df34 c132df20 c02490e0 c024bc34 df20: 0040 0020 c132df4c c132df38 c0209c2c c02490c8 bf02f8c0 0013 df40: c132df5c c132df50 c0208410 c0209bd4 c132dfbc c132df60 c0208f14 c0208410 df60: 4000 0288001f c2886000 c12a8c00 c12a8c00 bf02f894 0013 df80: c132dfbc c132c000 c132dfa8 4001 bf02f8c0 dfa0: 0013 c128dd58 c132dff4 c132dfc0 c022f8f4 bf02f8a4 dfc0: c128dd58 c12a8c00 c132dfd0 c132dfd0 c128dd58 dfe0: c022f860 c02191c8 c132dff8 c02191c8 c022f870 08f0 0402 Backtrace: [bf02f474] (kagen2_irq+0x0/0x3bc [kagen2_udc]) from [c02496d0] (handle_irq_event_percpu+0x30/0x178) r7:0020 r6: r5:c049cf70 r4:c12b9840 [c02496a0] (handle_irq_event_percpu+0x0/0x178) from [c0249878] (handle_irq_event+0x60/0x7c) [c0249818] (handle_irq_event+0x0/0x7c) from [c024bd38] (handle_edge_irq+0x114/0x16c) r6:f5006000 r5: r4:c049cf70 r3:f5006000 [c024bc24] (handle_edge_irq+0x0/0x16c) from [c02490e0] (generic_handle_irq+0x28/0x38) r4:0020 r3:c024bc24 [c02490b8] (generic_handle_irq+0x0/0x38) from [c0209c2c] (handle_IRQ+0x68/0x8c)
Re: Linux USB file storage gadget with new UDC
On Tue, 28 May 2013, victor yeo wrote: Now the UDC driver is working on both Linux and Windows host, meaning the read/write operation is ok. I still use the polling method, because waiting for interrupt is not reliable. Why aren't the interrupts reliable? Is this a known erratum for your hardware? Is it possible to contribute the code to Linux community? Yes. But first you should test it with other gadget drivers, not just g_file_storage. On the other hand, i run the USB 2.0 command verifier to test the gadget, the gadget crashes at BOS descriptor test. I think the gadget is not able to handle BOS descriptor, is the gadget driver setup function returning negative error code for BOS descriptor? The crash dump you attached contained this line: PC is at kagen2_irq+0x290/0x3bc [kagen2_udc] This means the crash occurred inside the UDC driver, not the gadget driver. 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
Re: Linux USB file storage gadget with new UDC
Hi,
I am able to solve the SCSI command timeout problem by adding a code
to check the hardware register busy bit continuously, in
kagen2_ep_queue():
do {
read_hardware_register_busy_bit
} while (hardware_is_busy)
This is silly. Drivers shouldn't poll in this way. That's what
interrupts are for.
however, it causes the linux prompt to be non-responsive because the
checking hardware register code is run continuously. If i add a
schedule() to the do-while loop, the kagen2_ep_queue() will not be
continued. How to go about fixing this dilemma?
I can't say much more without seeing the code. However, you should not
need to wait for the hardware to do something -- instead the interrupt
handler routine should be called when the hardware is finished.
Yes, it is silly. The hardware interrupt is not being generated for
every SCSI command received, so the driver has to poll. I put the
polling code in a thread, and this dilemma is fixed.
I still observe the SCSI_WRITE_10 command time out sometimes. When
time out happens, the gadget log shows:
g_file_storage gadget: invalid CBW: len 512 sig 0x6f007442
g_file_storage gadget: bulk-in set wedge
Is it because the gadget expects 31 byte command, but 512 byte data is
received instead?
The full UDC/gadget log is attached. Hope it is useful. If not, i will
add in more printk statements.
Thanks,
victor
EP1 OUT IRQ 0x28
[start_transfer] f8 6005fff0
ept1 out queue len 0x200, buffer 0xc1338000
before kagen2_ep_queue
after kagen2_ep_queue
kagen2_ep_queue 31 512 31
[kagen2_ep_queue] 43425355 4d
g_file_storage gadget: bulk-out, length 31:
: 55 53 42 43 4d 00 00 00 00 02 00 00 00 00 0a 2a
0010: 00 00 00 00 04 00 00 01 00 00 00 00 00 00 00
EP1 OUT IRQ 0x28
g_file_storage gadget: SCSI command: WRITE(10); Dc=10, Do=512; Hc=10, Ho=512
[start_transfer] 43425355 4d
ept1 out queue len 0x200, buffer 0xc1338000
before kagen2_ep_queue
after kagen2_ep_queue
kagen2_ep_queue 512 512 512
[kagen2_ep_queue] f8 fff0
g_file_storage gadget-lun0: file write 512 @ 2048 - 512
g_file_storage gadget: before calling send_status
g_file_storage gadget: bulk-in, length 13:
: 55 53 42 53 4d 00 00 00 00 00 00 00 00
[start_transfer] 53425355 4d
ept1 in queue len 0xd, buffer 0xc0c3c000
0: 0x53425355
4: 0x4d
8: 0x0
bulk_in_complete -- 0, 13/13
EP1 OUT IRQ 0x28
[start_transfer] f8 fff0
ept1 out queue len 0x200, buffer 0xc1338000
before kagen2_ep_queue
after kagen2_ep_queue
kagen2_ep_queue 31 512 31
[kagen2_ep_queue] 43425355 4e
g_file_storage gadget: bulk-out, length 31:
: 55 53 42 43 4e 00 00 00 00 02 00 00 00 00 0a 2a
0010: 00 00 00 00 06 00 00 01 00 00 00 00 00 00 00
EP1 OUT IRQ 0x28
g_file_storage gadget: SCSI command: WRITE(10); Dc=10, Do=512; Hc=10, Ho=512
[start_transfer] 43425355 4e
ept1 out queue len 0x200, buffer 0xc1338000
before kagen2_ep_queue
after kagen2_ep_queue
kagen2_ep_queue 512 512 512
[kagen2_ep_queue] 6f007442 7000
g_file_storage gadget-lun0: file write 512 @ 3072 - 512
g_file_storage gadget: before calling send_status
g_file_storage gadget: bulk-in, length 13:
: 55 53 42 53 4e 00 00 00 00 00 00 00 00
[start_transfer] 53425355 4e
ept1 in queue len 0xd, buffer 0xc0c3c000
0: 0x53425355
4: 0x4e
8: 0x0
bulk_in_complete -- 0, 13/13
EP1 OUT IRQ 0x28
[start_transfer] 6f007442 7000
ept1 out queue len 0x200, buffer 0xc1338000
before kagen2_ep_queue
after kagen2_ep_queue
kagen2_ep_queue 31 512 31
[kagen2_ep_queue] 43425355 4f
g_file_storage gadget: bulk-out, length 31:
: 55 53 42 43 4f 00 00 00 00 02 00 00 00 00 0a 2a
0010: 00 00 00 00 02 00 00 01 00 00 00 00 00 00 00
EP1 OUT IRQ 0x28
g_file_storage gadget: SCSI command: WRITE(10); Dc=10, Do=512; Hc=10, Ho=512
[start_transfer] 43425355 4f
ept1 out queue len 0x200, buffer 0xc1338000
before kagen2_ep_queue
after kagen2_ep_queue
kagen2_ep_queue 512 512 512
[kagen2_ep_queue] f8 fff0
g_file_storage gadget-lun0: file write 512 @ 1024 - 512
g_file_storage gadget: before calling send_status
g_file_storage gadget: bulk-in, length 13:
: 55 53 42 53 4f 00 00 00 00 00 00 00 00
[start_transfer] 53425355 4f
ept1 in queue len 0xd, buffer 0xc0c3c000
0: 0x53425355
4: 0x4f
8: 0x0
bulk_in_complete -- 0, 13/13
[start_transfer] f8 fff0
ept1 out queue len 0x200, buffer 0xc1338000
before kagen2_ep_queue
EP1 OUT IRQ 0x28
after kagen2_ep_queue
kagen2_ep_queue 31 512 31
EP1 OUT IRQ 0x28
[kagen2_ep_queue] 43425355 50
g_file_storage gadget: bulk-out, length 31:
: 55 53 42 43 50 00 00 00 00 02 00 00 00 00 0a 2a
0010: 00 00 00 00 06 00 00 01 00 00 00 00 00 00 00
g_file_storage gadget: SCSI command: WRITE(10); Dc=10, Do=512; Hc=10, Ho=512
[start_transfer] 43425355 50
ept1 out queue len 0x200, buffer 0xc1338000
before kagen2_ep_queue
after kagen2_ep_queue
kagen2_ep_queue 512 512 512
[kagen2_ep_queue] 6f007442 7000
g_file_storage gadget-lun0: file write 512 @ 3072 - 512
g_file_storage gadget: before calling send_status
g_file_storage gadget: bulk-in, length 13:
Re: Linux USB file storage gadget with new UDC
On Mon, 27 May 2013, victor yeo wrote: I can't say much more without seeing the code. However, you should not need to wait for the hardware to do something -- instead the interrupt handler routine should be called when the hardware is finished. Yes, it is silly. The hardware interrupt is not being generated for every SCSI command received, so the driver has to poll. I put the polling code in a thread, and this dilemma is fixed. Are you sure about this? If it is correct, you should _fix_ the interrupt problem. Don't try to work around it by creating a new thread. Figure out why there isn't an interrupt. Does your driver forget to set an interrupt-enable bit? I still observe the SCSI_WRITE_10 command time out sometimes. When time out happens, the gadget log shows: g_file_storage gadget: invalid CBW: len 512 sig 0x6f007442 g_file_storage gadget: bulk-in set wedge Is it because the gadget expects 31 byte command, but 512 byte data is received instead? No. It is because kagen2_ep_queue returned _before_ a new command was received, probably as a result of your polling thread. Since there was no new command, the data in the buffer was wrong. The full UDC/gadget log is attached. Hope it is useful. If not, i will add in more printk statements. You can see the problem in the log: g_file_storage gadget: bulk-in, length 13: : 55 53 42 53 50 00 00 00 00 00 00 00 00 [start_transfer] 53425355 50 ept1 in queue len 0xd, buffer 0xc0c3c000 0: 0x53425355 4: 0x50 8: 0x0 bulk_in_complete -- 0, 13/13 That was the end of the previous command. Now the gadget waits for a new command to arrive. [start_transfer] 6f007442 7000 ept1 out queue len 0x200, buffer 0xc1338000 before kagen2_ep_queue after kagen2_ep_queue kagen2_ep_queue 512 512 512 [kagen2_ep_queue] 6f007442 7000 kagen2_ep_queue returned but there was no interrupt. This means no new data was received, so the old data is still in the buffer. g_file_storage gadget: bulk_out_complete -- 0, 512/31 g_file_storage gadget: invalid CBW: len 512 sig 0x6f007442 g_file_storage gadget: bulk-in set wedge That 0x6f007442 is the old data from the previous command, as you can see from the log messages (it is the same data that was present when kagen2_ep_queue was called). 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
Re: Linux USB file storage gadget with new UDC
Hi,
Thanks! Indeed, the req-buf pointer was the one causing the crash
problem. It happened when combining multiple 512 bytes data. I have
fixed this bug.
Now my UDC driver is almost ready. That is probably one more SCSI
command timeout problem remaining, i am adding more printk to UDC
driver and studying it.
I am able to solve the SCSI command timeout problem by adding a code
to check the hardware register busy bit continuously, in
kagen2_ep_queue():
do {
read_hardware_register_busy_bit
} while (hardware_is_busy)
however, it causes the linux prompt to be non-responsive because the
checking hardware register code is run continuously. If i add a
schedule() to the do-while loop, the kagen2_ep_queue() will not be
continued. How to go about fixing this dilemma?
thanks,
victor
--
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
Re: Linux USB file storage gadget with new UDC
On Wed, 22 May 2013, victor yeo wrote:
I am able to solve the SCSI command timeout problem by adding a code
to check the hardware register busy bit continuously, in
kagen2_ep_queue():
do {
read_hardware_register_busy_bit
} while (hardware_is_busy)
This is silly. Drivers shouldn't poll in this way. That's what
interrupts are for.
however, it causes the linux prompt to be non-responsive because the
checking hardware register code is run continuously. If i add a
schedule() to the do-while loop, the kagen2_ep_queue() will not be
continued. How to go about fixing this dilemma?
I can't say much more without seeing the code. However, you should not
need to wait for the hardware to do something -- instead the interrupt
handler routine should be called when the hardware is finished.
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
Re: Linux USB file storage gadget with new UDC
Hi, When copying a file to the USB gadget, sometimes the USB gadget will hang, sometimes the USB gadget will crash, sometimes the copy is ok. From the UDC driver log, when the USB gadget crashes, the host is sending 16384 bytes of data. It seems that bulk_out_complete() is not able to handle it. [c03282ec] (dev_printk+0x0/0x3c) from [bf035924] (bulk_out_complete+0xc4/0x1a8 [g_file_storage]) r3:152a0e00 r2:a020d0e5 [bf02fac4] (kagen2_ep_queue+0x0/0x680 [kagen2_udc]) from [bf035f9c] (bulk_in_complete+0x24c/0x1010 [g_file_storage]) The meaning of printk of kagen2_ep_queue 512 16384 512 in UDC driver log: ka_req-req.actual is 512 ka_req-req.length is 16384 length from hardware FIFO is 512 Please see the attached UDC driver log and corresponding usbmon trace. I think the log says that bulk_out_complete() crashed when trying to dereference a NULL pointer. Maybe req-buf, maybe req-context, maybe something else. But you already know that bulk_out_complete() crashed; you don't need me to tell you that. What you _do_ need is to find out why the crash occurred. This means finding out which pointer is NULL. Thanks! Indeed, the req-buf pointer was the one causing the crash problem. It happened when combining multiple 512 bytes data. I have fixed this bug. Now my UDC driver is almost ready. That is probably one more SCSI command timeout problem remaining, i am adding more printk to UDC driver and studying it. Thanks, victor -- 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
Re: Linux USB file storage gadget with new UDC
On Mon, 20 May 2013, victor yeo wrote: When copying a file to the USB gadget, sometimes the USB gadget will hang, sometimes the USB gadget will crash, sometimes the copy is ok. From the UDC driver log, when the USB gadget crashes, the host is sending 16384 bytes of data. It seems that bulk_out_complete() is not able to handle it. [c03282ec] (dev_printk+0x0/0x3c) from [bf035924] (bulk_out_complete+0xc4/0x1a8 [g_file_storage]) r3:152a0e00 r2:a020d0e5 [bf02fac4] (kagen2_ep_queue+0x0/0x680 [kagen2_udc]) from [bf035f9c] (bulk_in_complete+0x24c/0x1010 [g_file_storage]) The meaning of printk of kagen2_ep_queue 512 16384 512 in UDC driver log: ka_req-req.actual is 512 ka_req-req.length is 16384 length from hardware FIFO is 512 Please see the attached UDC driver log and corresponding usbmon trace. I think the log says that bulk_out_complete() crashed when trying to dereference a NULL pointer. Maybe req-buf, maybe req-context, maybe something else. But you already know that bulk_out_complete() crashed; you don't need me to tell you that. What you _do_ need is to find out why the crash occurred. This means finding out which pointer is NULL. To do that, you need to add printk statements. I keep telling you this, but you don't go ahead and do it. 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
Re: Linux USB file storage gadget with new UDC
Hi, Another question from the bulk_out_complete() printout which is shown below. The req-actual is 512 byte. The bh-bulk_out_intended_length is 31. Is this a bug? g_file_storage gadget: get_next_command [start_transfer] 6f007442 7000 ept1 out queue len 0x200, buffer 0xc133 kagen2_ep_queue 512 512 512 g_file_storage gadget: bulk_out_complete -- 0, 512/31 . Well, it's a mistake. It might be a bug. If the host really did send a 13-byte packet then it's definitely a bug. But if the host sent a 512-byte packet then something else is wrong; it would mean the gadget was expecting a CBW packet but the host sent something else. Alan Stern When copying a file to the USB gadget, sometimes the USB gadget will hang, sometimes the USB gadget will crash, sometimes the copy is ok. From the UDC driver log, when the USB gadget crashes, the host is sending 16384 bytes of data. It seems that bulk_out_complete() is not able to handle it. [c03282ec] (dev_printk+0x0/0x3c) from [bf035924] (bulk_out_complete+0xc4/0x1a8 [g_file_storage]) r3:152a0e00 r2:a020d0e5 [bf02fac4] (kagen2_ep_queue+0x0/0x680 [kagen2_udc]) from [bf035f9c] (bulk_in_complete+0x24c/0x1010 [g_file_storage]) The meaning of printk of kagen2_ep_queue 512 16384 512 in UDC driver log: ka_req-req.actual is 512 ka_req-req.length is 16384 length from hardware FIFO is 512 Please see the attached UDC driver log and corresponding usbmon trace. Thanks, victor bulk_in_complete -- 0, 512/512 bulk_in_complete -- 0, 13/13 kagen2_ep_queue 31 512 31 bulk_in_complete -- 0, 512/512 bulk_in_complete -- 0, 13/13 kagen2_ep_queue 31 512 31 EP1 OUT IRQ 0x28 ep1_out: RX DMA done : NULL REQ on OUT EP-1 bulk_in_complete -- 0, 512/512 bulk_in_complete -- 0, 13/13 kagen2_ep_queue 31 512 31 EP1 OUT IRQ 0x28 ep1_out: RX DMA done : NULL REQ on OUT EP-1 kagen2_ep_queue 512 16384 512 kagen2_ep_queue 1024 16384 512 kagen2_ep_queue 1536 16384 512 kagen2_ep_queue 2048 16384 512 kagen2_ep_queue 2560 16384 512 kagen2_ep_queue 3072 16384 512 kagen2_ep_queue 3584 16384 512 kagen2_ep_queue 4096 16384 512 kagen2_ep_queue 4608 16384 512 kagen2_ep_queue 5120 16384 512 kagen2_ep_queue 5632 16384 512 kagen2_ep_queue 6144 16384 512 kagen2_ep_queue 6656 16384 512 kagen2_ep_queue 7168 16384 512 kagen2_ep_queue 7680 16384 512 kagen2_ep_queue 8192 16384 512 kagen2_ep_queue 8704 16384 512 kagen2_ep_queue 9216 16384 512 kagen2_ep_queue 9728 16384 512 kagen2_ep_queue 10240 16384 512 kagen2_ep_queue 10752 16384 512 kagen2_ep_queue 11264 16384 512 kagen2_ep_queue 11776 16384 512 kagen2_ep_queue 12288 16384 512 kagen2_ep_queue 12800 16384 512 kagen2_ep_queue 13312 16384 512 kagen2_ep_queue 13824 16384 512 kagen2_ep_queue 14336 16384 512 kagen2_ep_queue 14848 16384 512 kagen2_ep_queue 15360 16384 512 kagen2_ep_queue 15872 16384 512 kagen2_ep_queue 16384 16384 512 Unable to handle kernel NULL pointer dereference at virtual address 0004 pgd = c0204000 [0004] *pgd= Internal error: Oops - BUG: 17 [#1] PREEMPT ARM Modules linked in: g_file_storage kagen2_udc ath6kl_sdio ath6kl_core ka2000_sdio ka2000_sdhc CPU: 0Not tainted (3.4.4+ #43) PC is at dev_driver_string+0x30/0x44 LR is at __dev_printk+0x38/0x68 pc : [c0327ef8]lr : [c03280c4]psr: 2093 sp : c1333c08 ip : c1333c18 fp : c1333c14 r10: c0c38000 r9 : c12a0e34 r8 : 0001 r7 : c1289600 r6 : c129ec00 r5 : c1333c44 r4 : c129edd0 r3 : 0004 r2 : c1333c44 r1 : c129ec00 r0 : c129ec00 Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 0005717f Table: 01308000 DAC: 0017 Process file-storage-ga (pid: 123, stack limit = 0xc1332270) Stack: (0xc1333c08 to 0xc1334000) 3c00: c1333c3c c1333c18 c03280c4 c0327ed8 c0208eb8 c0208564 3c20: c129edd0 c12a0e00 c12896bc 0200 c1333c5c c1333c40 c0328320 c032809c 3c40: 0001 a020d0e5 c1333c4c c1333c64 c1333eb4 c1333c68 bf035924 c0328300 3c60: a020d0e5 152a0e00 152a0e00 c1333c78 000a 6013 3c80: c0c38000 c12a0e34 20313320 34660a3e 32613231 32203034 32323434 31363639 3ca0: 20532033 323a6942 3435303a 2d20313a 20353131 36393034 660a3c20 61323134 3cc0: 20303432 32343432 37313435 43203534 3a694220 35303a32 20313a34 30342030 3ce0: 3d203639 30303020 30303030 30302030 30303030 30203030 30303030 20303030 3d00: 30303030 30303030 30303020 30303030 30302030 30303030 30203030 30303030 3d20: 20303030 30303030 30303030 6166640a 34313936 34322030 34353234 34323831 3d40: 42205320 3a323a69 3a343530 312d2031 31203531 0a3c2033 36616664 30343139 3d60: 34343220 38343532 20323934 69422043 303a323a 313a3435 31203020 203d2033 3d80: 33353535 33353234 30613520 30303030 30302030 30303030 30203030 66640a30 3da0: 31393661 32203034 35323434 38353834 20532037 323a6f42 3435303a 2d20313a 3dc0: 20353131 3d203133 35353520 34323433 62352033 30303030 30203030 30303130 3de0: 20303030 30303038 38326130 30303020 30303030 30382033 30303030 30203830 3e00: 30303030 20303030 30303030 640a3030 39366166 20303431 32343432 37383435
Re: Linux USB file storage gadget with new UDC
On Thu, 16 May 2013, victor yeo wrote: Another question from the bulk_out_complete() printout which is shown below. The req-actual is 512 byte. The bh-bulk_out_intended_length is 31. Is this a bug? g_file_storage gadget: get_next_command [start_transfer] 6f007442 7000 ept1 out queue len 0x200, buffer 0xc133 kagen2_ep_queue 512 512 512 g_file_storage gadget: bulk_out_complete -- 0, 512/31 . Well, it's a mistake. It might be a bug. If the host really did send a 13-byte packet then it's definitely a bug. But if the host sent a 512-byte packet then something else is wrong; it would mean the gadget was expecting a CBW packet but the host sent something else. 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
Re: Linux USB file storage gadget with new UDC
Hi, All I can tell is that the gadget got hung after receiving the second WRITE command. Can you figure out where it got hung and why? Victor, you don't seem to get the big pattern that keeps repeating here. Every time something does wrong, you tell me about it. Then I point out that you didn't include any debugging information, so you send part of a log. Then I point out that you didn't send the entire log, or you didn't send logs for both the gadget and the host. You end up losing a day or two each time this happens. There's a very simple lesson: When you're asking for help in debugging a problem, _always_ include _all_ the data that might be relevant. Here's another lesson, which I have pointed out a few times before but you still don't seem to have understood: When you want to know where your driver is hanging up, put a bunch of printk statements in it, at all the important spots. Then you'll be able to see, in the log, the last printk that was executed before the hang. That will tell you where the problem is. Thanks. I will add more printk statements gradually. Now i discover if i write to a large text file ( 48k) on USB gadget, linux will crash. The full log of UDC and gadget driver when linux crashes, and corresponding usbmon trace are attached. If these logs are not helpful, i shall add more printk. thanks, victor bulk_in_complete -- 0, 13/13 bulk_in_complete -- 0, 13/13 EP1 OUT IRQ 0x28 ep1_out: RX DMA done : NULL REQ on OUT EP-1 Unable to handle kernel paging request at virtual address 4000 pgd = c0204000 [4000] *pgd= Internal error: Oops - BUG: 817 [#1] PREEMPT ARM Modules linked in: g_file_storage kagen2_udc ath6kl_sdio ath6kl_core ka2000_sdio ka2000_sdhc CPU: 0Not tainted (3.4.4+ #41) PC is at th, wValue, wIndex; unsigned int rdata, rdata1; // setup data valid val = readl(dev-base_addr + 0+0xfb0/0x199c [kagen2_udc] LR is at console_unlock+0x208/0x218 pc : [bf03000c]lr : [c0216824]psr: 2093 sp : c1347c68 ip : c1347b98 fp : c1347eb4 r10: c1328000 r9 : c12b4db4 r8 : 0001 r7 : c12fedd0 r6 : 0200 r5 : c1346000 r4 : c12b4d80 r3 : r2 : 0001 r1 : 015bb795 r0 : 4000 Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 0005717f Table: 01314000 DAC: 0017 Process file-storage-ga (pid: 122, stack limit = 0xc1346270) Stack: (0xc1347c68 to 0xc1348000) 7c60: 0200 c1347c78 000a 6013 7c80: c1328000 c12b4db4 4f203150 50205455 0a474e49 61760909 203d206c 64616572 7ca0: 6564286c 623e2d76 5f657361 72646461 30202b20 63383178 090a3b29 6c617609 7cc0: 203d2620 7830 3030 0a3b 61760909 3d7c206c 30783020 30323030 7ce0: 3b303030 090a0909 69727709 286c6574 2c6c6176 76656420 61623e2d 615f6573 7d00: 20726464 7830202b 29633831 7d090a3b 6c65090a 69206573 76282066 3d206c61 7d20: 7830203d 0a293832 700a7b09 746e6972 4522286b 4f203150 49205455 30205152 7d40: 5c782578 202c226e 296c6176 09090a3b 70652f2f 756f5f31 65642874 0a3b2976 7d60: 73740909 74654c6b 4253555f 7461642e 203d2061 736e7528 656e6769 6f6c2064 7d80: 6429676e 0a3b7665 61740909 656c6b73 63735f74 75646568 2628656c 4c6b7374 7da0: 555f7465 3b294253 09090a0a 206c6176 6572203d 286c6461 2d766564 7361623e 7dc0: 64615f65 2b207264 31783020 3b293061 7d090a09 6c65090a 69206573 76282066 7de0: 3d206c61 7830203d 0a293432 090a7b09 452f2f09 69203150 5249206e 09090a51 7e00: 206c6176 6572203d 286c6461 2d766564 7361623e 64615f65 2b207264 31783020 7e20: 3b293838 7609090a 26206c61 7830203d 3030 09090a3b 206c6176 7e40: 30203d7c 30303078 30303030 09093b32 7709090a 65746972 6176286c 64202c6c 7e60: 3e2d7665 65736162 6464615f 202b2072 38317830 0a3b2938 090a0909 65090a7d 7e80: 2065736c 28206669 c03ef7b0 c12b4d80 c12fedd0 c1289600 c12896f8 c12896e0 7ea0: 7e00 c1346018 c1347eec c1347eb8 bf035f9c bf02fa88 c12896dc 7ec0: c1289700 c1289600 00c8c000 c12896dc c1289700 c1289600 00c8c000 7ee0: c1347f54 c1347ef0 bf036b14 bf035e64 c12896e0 000a c1347f04 c0209bd4 7f00: c1347fbc be00 7e00 0001 00c8c000 00c88000 7f20: 0001 005f c12896dc c1289600 0001 005f c12896dc 7f40: c1346018 c1347fbc c1347f58 bf038ce8 bf0368d8 bf03a316 bf03a29f 7f60: 0015 c127ea80 c1347f8c c1347f78 c02349c8 c1289604 c13207e0 c1320540 7f80: c1347fac c1347f90 c03f2fc0 c02365d0 c1337e00 c1337e00 c1289600 bf037bc0 7fa0: 0013 c1347ff4 c1347fc0 c022f8f4 bf037bd0 7fc0: c1337e00 c1289600 c1347fd0 c1347fd0 c1337e00 7fe0: c022f860 c02191c8 c1347ff8 c02191c8 c022f870 Backtrace: [bf02fa78] (th, wValue, wIndex; unsigned int rdata, rdata1; // setup data valid val = readl(dev-base_addr + 0+0xa1c/0x199c [kagen2_udc]) from [bf035f9c] (bulk_in_complete+0x24c/0x1010
Re: Linux USB file storage gadget with new UDC
On Tue, 14 May 2013, victor yeo wrote: Thanks. I will add more printk statements gradually. Now i discover if i write to a large text file ( 48k) on USB gadget, linux will crash. The full log of UDC and gadget driver when linux crashes, and corresponding usbmon trace are attached. If these logs are not helpful, i shall add more printk. Unfortunately, I can't get anything useful out of the UDC driver crash log. It looks like the crash occurred somewhere inside the do_write() routine. Perhaps within the call to start_transfer(), or perhaps within the vfs_write() call. 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
Re: Linux USB file storage gadget with new UDC
Hi, Thanks. I will add more printk statements gradually. Now i discover if i write to a large text file ( 48k) on USB gadget, linux will crash. The full log of UDC and gadget driver when linux crashes, and corresponding usbmon trace are attached. If these logs are not helpful, i shall add more printk. Unfortunately, I can't get anything useful out of the UDC driver crash log. It looks like the crash occurred somewhere inside the do_write() routine. Perhaps within the call to start_transfer(), or perhaps within the vfs_write() call. Alan Stern Just curious. The crash log shows the following UDC driver code which is responsible to receive endpoint 0 setup data. However, the host PC is sending SCSI_WRITE_10 command at the time of the crash. These two does not correlate, right? unsigned int rdata, rdata1; // setup data valid val = readl(dev-base_addr + 0+0xfb0/0x199c [kagen2_udc] thanks, victor -- 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
Re: Linux USB file storage gadget with new UDC
On Tue, 14 May 2013, victor yeo wrote: Just curious. The crash log shows the following UDC driver code which is responsible to receive endpoint 0 setup data. However, the host PC is sending SCSI_WRITE_10 command at the time of the crash. These two does not correlate, right? unsigned int rdata, rdata1; // setup data valid val = readl(dev-base_addr + 0+0xfb0/0x199c [kagen2_udc] The crash log should not include any driver code. What data were you writing to the gadget when the crash occurred? Were you sending the source code for the UDC driver? If you were, maybe that data got written to a wrong area in memory. 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
Re: Linux USB file storage gadget with new UDC
Hi, Ok, i just fixed the last three bytes in the bulk-out transfer problem. Please see below for the log. Now the last three bytes are read correctly. After SCSI_WRITE_10 is received, the gadget driver prints g_file_storage gadget: disconnect or port reset, it means USB reset interrupt is received by the UDC driver. I don't know why USB reset interrupt is triggered. Then you need to figure out why. Have you checked the dmesg log and usbmon trace on the host? Incidentally, for debugging it will help if you enable CONFIG_PRINTK_TIME in the gadget's kernel. Thanks, i will enable the CONFIG_PRINTK_TIME. Nonetheless, now the gadget driver and UDC driver are able to process some SCSI_WRITE_10 commands (i ignore the USB reset interrupt in UDC driver). Please see the attached usbmon log. Will the log help? Thanks, victor scsi_write_10_again04.log Description: Binary data
Re: Linux USB file storage gadget with new UDC
On Mon, 13 May 2013, victor yeo wrote: Thanks, i will enable the CONFIG_PRINTK_TIME. Nonetheless, now the gadget driver and UDC driver are able to process some SCSI_WRITE_10 commands (i ignore the USB reset interrupt in UDC driver). Please see the attached usbmon log. Will the log help? All I can tell is that the gadget got hung after receiving the second WRITE command. Can you figure out where it got hung and why? Victor, you don't seem to get the big pattern that keeps repeating here. Every time something does wrong, you tell me about it. Then I point out that you didn't include any debugging information, so you send part of a log. Then I point out that you didn't send the entire log, or you didn't send logs for both the gadget and the host. You end up losing a day or two each time this happens. There's a very simple lesson: When you're asking for help in debugging a problem, _always_ include _all_ the data that might be relevant. Here's another lesson, which I have pointed out a few times before but you still don't seem to have understood: When you want to know where your driver is hanging up, put a bunch of printk statements in it, at all the important spots. Then you'll be able to see, in the log, the last printk that was executed before the hang. That will tell you where the problem is. 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
Re: Linux USB file storage gadget with new UDC
Hi, Obviously this disconnect or port reset message is related to the EP1 OUT IRQ 0x28 line above. But why? It looks like another bug. I see you still haven't fixed the last three bytes in the bulk-out transfer. Ok, i just fixed the last three bytes in the bulk-out transfer problem. Please see below for the log. Now the last three bytes are read correctly. After SCSI_WRITE_10 is received, the gadget driver prints g_file_storage gadget: disconnect or port reset, it means USB reset interrupt is received by the UDC driver. I don't know why USB reset interrupt is triggered. [start_transfer] ept1 out queue len 0x200, buffer 0xc1298000 g_file_storage gadget: bulk-out, length 31: : 55 53 42 43 f5 00 00 00 00 02 00 00 00 00 0a 2a 0010: 00 00 00 00 01 00 00 01 00 00 00 00 00 00 00 g_file_storage gadget: SCSI command: WRITE(10); Dc=10, Do=512; Hc=10, Ho=512 [start_transfer] 43425355 f5 ept1 out queue len 0x200, buffer 0xc1298000 g_file_storage gadget: disconnect or port reset g_file_storage gadget: do_scsi_command unlink (ep1) pio kagen2_set_halt 1 0 g_file_storage gadget: bulk-out, length 0: g_file_storage gadget: bulk_out_complete -- 0, 0/512 g_file_storage gadget: reset config g_file_storage gadget: reset interface g_file_storage gadget: handle_exception g_file_storage gadget: ep0-setup, length 8: : 80 06 00 01 00 00 40 00 . Thanks, victor -- 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
Re: Linux USB file storage gadget with new UDC
On Fri, 10 May 2013, victor yeo wrote: Hi, Obviously this disconnect or port reset message is related to the EP1 OUT IRQ 0x28 line above. But why? It looks like another bug. I see you still haven't fixed the last three bytes in the bulk-out transfer. Ok, i just fixed the last three bytes in the bulk-out transfer problem. Please see below for the log. Now the last three bytes are read correctly. After SCSI_WRITE_10 is received, the gadget driver prints g_file_storage gadget: disconnect or port reset, it means USB reset interrupt is received by the UDC driver. I don't know why USB reset interrupt is triggered. Then you need to figure out why. Have you checked the dmesg log and usbmon trace on the host? Incidentally, for debugging it will help if you enable CONFIG_PRINTK_TIME in the gadget's kernel. 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
Re: Linux USB file storage gadget with new UDC
Hi,
That's right. Interrupts can occur at almost any time (on
multiprocessor systems they can occur even when interrupts are disabled
on some of the CPUs).
I am confused. I add the spinlock functions to kagen2_ep_queue function.
spin_lock_irqsave(dev-lock, flags);
..
spin_unlock_irqrestore(dev-lock, flags);
When kagen2_ep_queue function is called, the error BUG: scheduling
while atomic: swapper/0/0x0002 occurs. I test the same spinlock
functions in other device module. It is ok in other device module.
While the function holds a spinlock, it is not allowed to sleep.
The BUG occurs because kagen2_ep_queue must call some function that can
sleep. But since you did not provide the rest of the BUG message
(including the stack trace), I can't tell what function it calls.
The BUG: scheduling while atomic is solved. Need to add extra
spinlock functions for req-complete() as below:
spin_unlock(dev-lock);
req-complete(ep, req);
spin_lock(dev-lock);
Now, the SCSI_WRITE_10 command is received but the data is not
received. There is disconnect or port reset after SCSI_WRITE_10
command. Please see below:
[start_transfer] 613e2d71 61757463
ept1 out queue len 0x200, buffer 0xc1338000
g_file_storage gadget: bulk-out, length 31:
: 55 53 42 43 f6 00 00 00 00 02 00 00 00 00 0a 2a
0010: 00 00 00 00 01 00 00 01 00 00 00 00 80 b7 21
EP1 OUT IRQ 0x28
g_file_storage gadget: disconnect or port reset
g_file_storage gadget: SCSI command: WRITE(10); Dc=10, Do=512; Hc=10, Ho=512
[start_transfer] 43425355 f6
ept1 out queue len 0x200, buffer 0xc1338000
g_file_storage gadget: do_scsi_command
unlink (ep1) pio
kagen2_set_halt 1 0
g_file_storage gadget: bulk-out, length 0:
g_file_storage gadget: bulk_out_complete -- 0, 0/512
g_file_storage gadget: reset config
g_file_storage gadget: reset interface
g_file_storage gadget: handle_exception
g_file_storage gadget: do_scsi_command is from extra DBG statement
that i added in file_storage.c.
if (do_scsi_command(fsg) || finish_reply(fsg))
{
DBG(fsg, do_scsi_command\n);
continue;
}
thanks,
victor
--
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
Re: Linux USB file storage gadget with new UDC
On Thu, 9 May 2013, victor yeo wrote: The BUG: scheduling while atomic is solved. Need to add extra spinlock functions for req-complete() as below: spin_unlock(dev-lock); req-complete(ep, req); spin_lock(dev-lock); Yes, I forgot to mention that. Now, the SCSI_WRITE_10 command is received but the data is not received. There is disconnect or port reset after SCSI_WRITE_10 command. Please see below: [start_transfer] 613e2d71 61757463 ept1 out queue len 0x200, buffer 0xc1338000 g_file_storage gadget: bulk-out, length 31: : 55 53 42 43 f6 00 00 00 00 02 00 00 00 00 0a 2a 0010: 00 00 00 00 01 00 00 01 00 00 00 00 80 b7 21 EP1 OUT IRQ 0x28 g_file_storage gadget: disconnect or port reset Obviously this disconnect or port reset message is related to the EP1 OUT IRQ 0x28 line above. But why? It looks like another bug. I see you still haven't fixed the last three bytes in the bulk-out transfer. 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
Re: Linux USB file storage gadget with new UDC
Hi, It is likely that this bug occurs because you don't use a spinlock in kagen2_ep_queue. Does the interrupt handler routine use a spinlock? Spinlock is Not used in interrupt handler routine. Then that's the reason for this bug. [start_transfer] 53425355 10d ept1 out queue len 0x200, buffer 0xc1304000 g_file_storage gadget: bulk-out, length 31: Is the kagen2_ep_queue function gotten interrupted here? So the kagen2_ep_queue and interrupt routine need spinlock for synchronisation? That's right. Interrupts can occur at almost any time (on multiprocessor systems they can occur even when interrupts are disabled on some of the CPUs). I am confused. I add the spinlock functions to kagen2_ep_queue function. spin_lock_irqsave(dev-lock, flags); .. spin_unlock_irqrestore(dev-lock, flags); When kagen2_ep_queue function is called, the error BUG: scheduling while atomic: swapper/0/0x0002 occurs. I test the same spinlock functions in other device module. It is ok in other device module. thanks, victor -- 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
Re: Linux USB file storage gadget with new UDC
On Wed, 8 May 2013, victor yeo wrote: Is the kagen2_ep_queue function gotten interrupted here? So the kagen2_ep_queue and interrupt routine need spinlock for synchronisation? That's right. Interrupts can occur at almost any time (on multiprocessor systems they can occur even when interrupts are disabled on some of the CPUs). I am confused. I add the spinlock functions to kagen2_ep_queue function. spin_lock_irqsave(dev-lock, flags); .. spin_unlock_irqrestore(dev-lock, flags); When kagen2_ep_queue function is called, the error BUG: scheduling while atomic: swapper/0/0x0002 occurs. I test the same spinlock functions in other device module. It is ok in other device module. While the function holds a spinlock, it is not allowed to sleep. The BUG occurs because kagen2_ep_queue must call some function that can sleep. But since you did not provide the rest of the BUG message (including the stack trace), I can't tell what function it calls. 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
Re: Linux USB file storage gadget with new UDC
Hi, How the UDC driver know when the request is really complete? An OUT request is really complete when either: The total number of bytes copied into req.buffer (i.e., req.actual) is equal to req.length, or The number of bytes received in the last packet is smaller than ep.maxpacket. I made some changes regarding req.actual. Now the UDC driver still cannot process SCSI_WRITE_10 command. Please see the attached UDC driver log when i try to write to a text file. There should be three SCSI commands in the log: SCSI_REQUEST_SENSE, SCSI_TEST_UNIT_READY and SCSI_WRITE_10. SCSI_WRITE_10 is not received properly. Thanks, victor g_file_storage gadget: bulk-out, length 31: : 55 53 42 43 0d 01 00 00 12 00 00 00 80 00 06 03 0010: 00 00 00 12 00 00 00 00 00 00 00 00 c3 63 4a g_file_storage gadget: SCSI command: REQUEST SENSE; Dc=6, Di=18; Hc=6, Hi=18 g_file_storage gadget: bulk-in, length 18: : 70 00 06 00 00 00 00 0a 00 00 00 00 29 00 00 00 0010: 00 00 [start_transfer] 60070 a00 ept1 in queue len 0x12, buffer 0xc1344000 0: 0x60070 4: 0xa00 8: 0x0 c: 0x29 bulk_in_complete -- 0, 18/18 g_file_storage gadget: bulk-in, length 13: : 55 53 42 53 0d 01 00 00 00 00 00 00 00 [start_transfer] 53425355 10d ept1 in queue len 0xd, buffer 0xc1304000 0: 0x53425355 4: 0x10d 8: 0x0 bulk_in_complete -- 0, 13/13 EP1 OUT IRQ 0x28 ep1_out: RX DMA done : NULL REQ on OUT EP-1 [start_transfer] 60070 a00 ept1 out queue len 0x200, buffer 0xc1344000 g_file_storage gadget: bulk-out, length 31: : 55 53 42 43 0e 01 00 00 00 00 00 00 00 00 06 00 0010: 00 00 00 00 00 00 00 00 00 00 00 00 c3 63 4a g_file_storage gadget: SCSI command: TEST UNIT READY; Dc=6, Dn=0; Hc=6, Hn=0 g_file_storage gadget: bulk-in, length 13: : 55 53 42 53 0e 01 00 00 00 00 00 00 00 [start_transfer] 53425355 10e ept1 in queue len 0xd, buffer 0xc1344000 0: 0x53425355 4: 0x10e 8: 0x0 bulk_in_complete -- 0, 13/13 EP1 OUT IRQ 0x28 ep1_out: RX DMA done : NULL REQ on OUT EP-1 [start_transfer] 53425355 10d ept1 out queue len 0x200, buffer 0xc1304000 g_file_storage gadget: bulk-out, length 31: EP1 OUT IRQ 0x28 epnum 1 in 0 len 0 512 0 g_file_storage gadget: bulk-out, length 0: g_file_storage gadget: bulk_out_complete -- 0, 0/31 g_file_storage gadget: bulk_out_complete -- 0, 0/31 g_file_storage gadget: invalid CBW: len 0 sig 0x43425355 g_file_storage gadget: bulk-in set wedge g_file_storage gadget: get_next_command [start_transfer] 43425355 10f ept1 out queue len 0x200, buffer 0xc1304000
Re: Linux USB file storage gadget with new UDC
On Tue, 7 May 2013, victor yeo wrote: Hi, How the UDC driver know when the request is really complete? An OUT request is really complete when either: The total number of bytes copied into req.buffer (i.e., req.actual) is equal to req.length, or The number of bytes received in the last packet is smaller than ep.maxpacket. I made some changes regarding req.actual. Now the UDC driver still cannot process SCSI_WRITE_10 command. Please see the attached UDC driver log when i try to write to a text file. There should be three SCSI commands in the log: SCSI_REQUEST_SENSE, SCSI_TEST_UNIT_READY and SCSI_WRITE_10. SCSI_WRITE_10 is not received properly. No, it isn't. Here's what the log says: EP1 OUT IRQ 0x28 ep1_out: RX DMA done : NULL REQ on OUT EP-1 [start_transfer] 53425355 10d ept1 out queue len 0x200, buffer 0xc1304000 g_file_storage gadget: bulk-out, length 31: This is from bulk_out_complete, when the WRITE(10) was received. EP1 OUT IRQ 0x28 epnum 1 in 0 len 0 512 0 g_file_storage gadget: bulk-out, length 0: This line indicates a bug. It means the UDC driver called bulk_out_complete again, even though the previous request was no longer queued and no new requests had been submitted yet. It is likely that this bug occurs because you don't use a spinlock in kagen2_ep_queue. Does the interrupt handler routine use a spinlock? Maybe you haven't noticed this, but the REQUEST SENSE and TEST UNIT READY commands weren't received correctly either. The last three bytes in each command should be 0, but they aren't. They are: c3 63 4a. Where did those values come from? 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
Re: Linux USB file storage gadget with new UDC
Hi, I made some changes regarding req.actual. Now the UDC driver still cannot process SCSI_WRITE_10 command. Please see the attached UDC driver log when i try to write to a text file. There should be three SCSI commands in the log: SCSI_REQUEST_SENSE, SCSI_TEST_UNIT_READY and SCSI_WRITE_10. SCSI_WRITE_10 is not received properly. No, it isn't. Here's what the log says: EP1 OUT IRQ 0x28 ep1_out: RX DMA done : NULL REQ on OUT EP-1 [start_transfer] 53425355 10d ept1 out queue len 0x200, buffer 0xc1304000 g_file_storage gadget: bulk-out, length 31: This is from bulk_out_complete, when the WRITE(10) was received. EP1 OUT IRQ 0x28 epnum 1 in 0 len 0 512 0 g_file_storage gadget: bulk-out, length 0: This line indicates a bug. It means the UDC driver called bulk_out_complete again, even though the previous request was no longer queued and no new requests had been submitted yet. It is likely that this bug occurs because you don't use a spinlock in kagen2_ep_queue. Does the interrupt handler routine use a spinlock? Spinlock is Not used in interrupt handler routine. [start_transfer] 53425355 10d ept1 out queue len 0x200, buffer 0xc1304000 g_file_storage gadget: bulk-out, length 31: Is the kagen2_ep_queue function gotten interrupted here? So the kagen2_ep_queue and interrupt routine need spinlock for synchronisation? EP1 OUT IRQ 0x28 epnum 1 in 0 len 0 512 0 g_file_storage gadget: bulk-out, length 0: Maybe you haven't noticed this, but the REQUEST SENSE and TEST UNIT READY commands weren't received correctly either. The last three bytes in each command should be 0, but they aren't. They are: c3 63 4a. Where did those values come from? Yes, i haven't noticed the c3 63 4a. Clearly the last three bytes should be zero. Maybe the UDC driver has a bug (Do the last 3 bytes matter for file gadget? ). Here is the usbmon trace that corresponds to the UDC log. It is the proof that the last three bytes are zero. Thanks, victor scsi_write_10_again02.log Description: Binary data
Re: Linux USB file storage gadget with new UDC
On Tue, 7 May 2013, victor yeo wrote: It is likely that this bug occurs because you don't use a spinlock in kagen2_ep_queue. Does the interrupt handler routine use a spinlock? Spinlock is Not used in interrupt handler routine. Then that's the reason for this bug. [start_transfer] 53425355 10d ept1 out queue len 0x200, buffer 0xc1304000 g_file_storage gadget: bulk-out, length 31: Is the kagen2_ep_queue function gotten interrupted here? So the kagen2_ep_queue and interrupt routine need spinlock for synchronisation? That's right. Interrupts can occur at almost any time (on multiprocessor systems they can occur even when interrupts are disabled on some of the CPUs). Maybe you haven't noticed this, but the REQUEST SENSE and TEST UNIT READY commands weren't received correctly either. The last three bytes in each command should be 0, but they aren't. They are: c3 63 4a. Where did those values come from? Yes, i haven't noticed the c3 63 4a. Clearly the last three bytes should be zero. Maybe the UDC driver has a bug (Do the last 3 bytes matter for file gadget? ). Well, it certainly matters if some of the bytes in the data blocks for a WRITE command get messed up! 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
Re: Linux USB file storage gadget with new UDC
Hi,
Please see the attached kagen2_ep_queue(). As long as it is called, it
will queue the request and read packets from hardware, in the same
if-else branch for bulk out endpoint. The interrupt handler will NOT
accept packet if request is NOT queued. If request is queued,
interrupt handler will accept the packet.
This code is wrong. See what happens when a request for ep1-out is
submitted:
/* ep1 OUT endpoint */
else if (in == 0)
{
// read from EP1 OUT buffer
if (num == 1)
{
unsigned int val;
unsigned int val_arr[8];
int i;
// get byte count from hardware
val = readl(dev-base_addr + 0x008);
len = val 0xFF;
Why do you expect there to be any data in the hardware FIFO at this
point? You said that the hardware will not accept any data if a
request is not queued. Well, before this point the request wasn't
queued, so there shouldn't be any data.
I am sorry for unclear writing. What i mean is: If a request is not
queued, the hardware will still accept data, but interrupt controller
will not read the data from the hardware FIFO.
// read from hardware fifo1 data
for (i = 0; i len/4; i++)
{
val_arr[i] = readl(dev-base_addr + 0x084);
}
val_arr is declared as an array of 8 unsigned ints. That means its
total size is 32 bytes. What happens if len 32? You will end up
overwriting part of the stack.
Yes! This is a bug. I only thought about the 31 byte CBW for bulk out
endpoint. I forgot about the SCSI_WRITE_10 command. Thanks!!
list_add_tail(ka_req-queue, ka_ep-queue);
ka_req-req.actual = len;
memcpy(ka_req-req.buf, val_arr[0], len);
ka_req-req.complete(ka_ep-ep, ka_req-req);
You should not call req.complete until the request really is complete.
For example, what happens here if the host hasn't sent any packets yet?
Or what happens if req is waiting to receive 1024 bytes but the host
has sent only 512 bytes so far?
How the UDC driver know when the request is really complete?
Also, all the data gets copied _twice_: once from the hardware FIFO
into val_arr, and then again from val_arr into req.buf. That's a waste
of time; the data should be copied directly from the FIFO into req.buf.
Agree.
2) Repeatedly (many many times), the same SCSI_READ_10 command is
received by UDC driver, processed by gadget driver, and UDC driver
sends out data and CSW to host. On usbmon trace, only one instance of
the SCSI_READ_10 is observed.
This is probably because you are copying the same data from the FIFO to
req.buffer many times.
I am curious about it. After data is read from FIFO, the FIFO will
become empty. Still cannot figure out how the same data is read from
the FIFO many times.
Thanks,
victor
--
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
Re: Linux USB file storage gadget with new UDC
On Wed, 1 May 2013, victor yeo wrote: Why do you expect there to be any data in the hardware FIFO at this point? You said that the hardware will not accept any data if a request is not queued. Well, before this point the request wasn't queued, so there shouldn't be any data. I am sorry for unclear writing. What i mean is: If a request is not queued, the hardware will still accept data, but interrupt controller will not read the data from the hardware FIFO. All right. I'm not sure whether that is a good idea or not, but it should work for g-file-storage. list_add_tail(ka_req-queue, ka_ep-queue); ka_req-req.actual = len; memcpy(ka_req-req.buf, val_arr[0], len); ka_req-req.complete(ka_ep-ep, ka_req-req); You should not call req.complete until the request really is complete. For example, what happens here if the host hasn't sent any packets yet? Or what happens if req is waiting to receive 1024 bytes but the host has sent only 512 bytes so far? How the UDC driver know when the request is really complete? An OUT request is really complete when either: The total number of bytes copied into req.buffer (i.e., req.actual) is equal to req.length, or The number of bytes received in the last packet is smaller than ep.maxpacket. 2) Repeatedly (many many times), the same SCSI_READ_10 command is received by UDC driver, processed by gadget driver, and UDC driver sends out data and CSW to host. On usbmon trace, only one instance of the SCSI_READ_10 is observed. This is probably because you are copying the same data from the FIFO to req.buffer many times. I am curious about it. After data is read from FIFO, the FIFO will become empty. Still cannot figure out how the same data is read from the FIFO many times. Maybe the UDC driver needs to do something extra to tell the hardware when the FIFO becomes empty. 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
Re: Linux USB file storage gadget with new UDC
On Fri, 26 Apr 2013, victor yeo wrote:
Please see the attached kagen2_ep_queue(). As long as it is called, it
will queue the request and read packets from hardware, in the same
if-else branch for bulk out endpoint. The interrupt handler will NOT
accept packet if request is NOT queued. If request is queued,
interrupt handler will accept the packet.
This code is wrong. See what happens when a request for ep1-out is
submitted:
/* ep1 OUT endpoint */
else if (in == 0)
{
// read from EP1 OUT buffer
if (num == 1)
{
unsigned int val;
unsigned int val_arr[8];
int i;
// get byte count from hardware
val = readl(dev-base_addr + 0x008);
len = val 0xFF;
Why do you expect there to be any data in the hardware FIFO at this
point? You said that the hardware will not accept any data if a
request is not queued. Well, before this point the request wasn't
queued, so there shouldn't be any data.
// read from hardware fifo1 data
for (i = 0; i len/4; i++)
{
val_arr[i] = readl(dev-base_addr + 0x084);
}
val_arr is declared as an array of 8 unsigned ints. That means its
total size is 32 bytes. What happens if len 32? You will end up
overwriting part of the stack.
list_add_tail(ka_req-queue, ka_ep-queue);
ka_req-req.actual = len;
memcpy(ka_req-req.buf, val_arr[0], len);
ka_req-req.complete(ka_ep-ep, ka_req-req);
You should not call req.complete until the request really is complete.
For example, what happens here if the host hasn't sent any packets yet?
Or what happens if req is waiting to receive 1024 bytes but the host
has sent only 512 bytes so far?
Also, all the data gets copied _twice_: once from the hardware FIFO
into val_arr, and then again from val_arr into req.buf. That's a waste
of time; the data should be copied directly from the FIFO into req.buf.
list_del_init(ka_req-queue);
// clear hardware OUT1CS register
val = readl(dev-base_addr + 0x008);
val = 0x00ff;
writel(val, dev-base_addr + 0x008);
Does this really clear the register? It looks like the low-order 8
bits (which got read into len earlier) remain unchanged.
}
}
There probably are many other problems like these which need to be
fixed.
Somehow, there is still timing problem in UDC driver and it is hard to
pin down the root cause. It could be due to interaction of UDC driver
queue() and gadget driver fsg_main_thread() main loop.
1) When writing to gen2 gadget, SCSI_READ_10 or or SCSI_REQUEST_SENSE
commands are received by UDC driver, but gadget did not process the
commands. (cannot get past get_next_command() in fsg_main_thread)
Then add printk statements inside get_next_command() so you can see
exactly where it's getting stuck.
2) Repeatedly (many many times), the same SCSI_READ_10 command is
received by UDC driver, processed by gadget driver, and UDC driver
sends out data and CSW to host. On usbmon trace, only one instance of
the SCSI_READ_10 is observed.
This is probably because you are copying the same data from the FIFO to
req.buffer many times.
3) More severe case, if removing one printk statement in
bulk_in_complete(), USB gadget device cannot be recognised by host.
I think there must still be many bugs remaining in the UDC driver.
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
Re: Linux USB file storage gadget with new UDC
Hi, This is the stack dump when the completion routine is called without an interrupt occurring first, is it useful? Backtrace: [c020c0fc] (dump_backtrace+0x0/0x110) from [c03ef5e4] (dump_stack+0x18/0x1c) r6:bf030da8 r5:c12aec00 r4:c12b4c00 r3:00f8 [c03ef5cc] (dump_stack+0x0/0x1c) from [bf02fecc] (kagen2_ep_queue+0x520/0x598 [kagen2_udc]) [bf02f9ac] (kagen2_ep_queue+0x0/0x598 [kagen2_udc]) from [bf036068] (fsg_lun_open+0x578/0x1278 [g_file_storage]) [bf035f20] (fsg_lun_open+0x430/0x1278 [g_file_storage]) from [bf037cd4] (fsg_main_thread+0x10c/0x155c [g_file_storage]) r8: r7:0001 r6:c12896c0 r5:c12896bc r4:c1289600 [bf037bc8] (fsg_main_thread+0x0/0x155c [g_file_storage]) from [c022f8f4] (kthread+0x94/0xa0) [c022f860] (kthread+0x0/0xa0) from [c02191c8] (do_exit+0x0/0x6f0) r6:c02191c8 r5:c022f860 r4:c1327e00 This shows that kagen2_ep_queue() calls kareq-req.complete. Perhaps indirectly, through another function. If this is true then it's probably a bug. You should check it out. Yes, the kagen2_ep_queue() calls req-req.complete directly. I thought this is necessary to pass the packets to gadget driver for processing? req-req.complete is mapped to bulk_out_complete() or bulk_in_complete(). thanks, victor -- 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
Re: Linux USB file storage gadget with new UDC
On Thu, 25 Apr 2013, victor yeo wrote: Hi, This is the stack dump when the completion routine is called without an interrupt occurring first, is it useful? Backtrace: [c020c0fc] (dump_backtrace+0x0/0x110) from [c03ef5e4] (dump_stack+0x18/0x1c) r6:bf030da8 r5:c12aec00 r4:c12b4c00 r3:00f8 [c03ef5cc] (dump_stack+0x0/0x1c) from [bf02fecc] (kagen2_ep_queue+0x520/0x598 [kagen2_udc]) [bf02f9ac] (kagen2_ep_queue+0x0/0x598 [kagen2_udc]) from [bf036068] (fsg_lun_open+0x578/0x1278 [g_file_storage]) [bf035f20] (fsg_lun_open+0x430/0x1278 [g_file_storage]) from [bf037cd4] (fsg_main_thread+0x10c/0x155c [g_file_storage]) r8: r7:0001 r6:c12896c0 r5:c12896bc r4:c1289600 [bf037bc8] (fsg_main_thread+0x0/0x155c [g_file_storage]) from [c022f8f4] (kthread+0x94/0xa0) [c022f860] (kthread+0x0/0xa0) from [c02191c8] (do_exit+0x0/0x6f0) r6:c02191c8 r5:c022f860 r4:c1327e00 This shows that kagen2_ep_queue() calls kareq-req.complete. Perhaps indirectly, through another function. If this is true then it's probably a bug. You should check it out. Yes, the kagen2_ep_queue() calls req-req.complete directly. I thought this is necessary to pass the packets to gadget driver for processing? It is necessary to call req.complete when the request has _completed_! That's why the callback is named complete! req-req.complete is mapped to bulk_out_complete() or bulk_in_complete(). A bulk-out request isn't complete until the data has been received from the host. A bulk-in request isn't complete until the data has been sent to the host (or at least copied into a hardware buffer). kagen2_ep_queue() gets called when the bulk-out request is submitted, right? So the request is not complete at that time. It isn't complete until the host has sent the data. After all, if you haven't received the packets from the host yet, how can you pass the packets to the gadget driver for processing? 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
Re: Linux USB file storage gadget with new UDC
Hi, Yes, the kagen2_ep_queue() calls req-req.complete directly. I thought this is necessary to pass the packets to gadget driver for processing? It is necessary to call req.complete when the request has _completed_! That's why the callback is named complete! req-req.complete is mapped to bulk_out_complete() or bulk_in_complete(). A bulk-out request isn't complete until the data has been received from the host. A bulk-in request isn't complete until the data has been sent to the host (or at least copied into a hardware buffer). kagen2_ep_queue() gets called when the bulk-out request is submitted, right? So the request is not complete at that time. It isn't complete until the host has sent the data. After all, if you haven't received the packets from the host yet, how can you pass the packets to the gadget driver for processing? Alan Stern For bulk out endpoint, I code the kagen2_ep_queue() to read the packets from the USB hardware, then call bulk_out_complete() via req-req.complete. Is this the correct way? Or i should only read the bulk out endpoint when bulk-out endpoint interrupt is received? thanks, victor -- 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
Re: Linux USB file storage gadget with new UDC
On Thu, 25 Apr 2013, victor yeo wrote: For bulk out endpoint, I code the kagen2_ep_queue() to read the packets from the USB hardware, then call bulk_out_complete() via req-req.complete. Is this the correct way? While kagen2_ep_queue() is running, there shouldn't be any packets in the USB hardware. The hardware should refuse to accept any packets, sending NAKs back to the host, until a request has been submitted and queued. Or i should only read the bulk out endpoint when bulk-out endpoint interrupt is received? When the request is queued, that's when you should tell the hardware to accept data from the host. After that, each time a packet arrives from the host, either the hardware or the UDC driver should store the packet data in the request's buffer. When the buffer is full or a short packet is received (the UDC driver's interrupt handler will know when this happens) then the UDC driver should call req.complete. 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
Re: Linux USB file storage gadget with new UDC
Hi,
While kagen2_ep_queue() is running, there shouldn't be any packets in
the USB hardware. The hardware should refuse to accept any packets,
sending NAKs back to the host, until a request has been submitted and
queued.
When the request is queued, that's when you should tell the hardware to
accept data from the host. After that, each time a packet arrives from
the host, either the hardware or the UDC driver should store the packet
data in the request's buffer. When the buffer is full or a short
packet is received (the UDC driver's interrupt handler will know when
this happens) then the UDC driver should call req.complete.
Please see the attached kagen2_ep_queue(). As long as it is called, it
will queue the request and read packets from hardware, in the same
if-else branch for bulk out endpoint. The interrupt handler will NOT
accept packet if request is NOT queued. If request is queued,
interrupt handler will accept the packet.
Somehow, there is still timing problem in UDC driver and it is hard to
pin down the root cause. It could be due to interaction of UDC driver
queue() and gadget driver fsg_main_thread() main loop.
1) When writing to gen2 gadget, SCSI_READ_10 or or SCSI_REQUEST_SENSE
commands are received by UDC driver, but gadget did not process the
commands. (cannot get past get_next_command() in fsg_main_thread)
2) Repeatedly (many many times), the same SCSI_READ_10 command is
received by UDC driver, processed by gadget driver, and UDC driver
sends out data and CSW to host. On usbmon trace, only one instance of
the SCSI_READ_10 is observed.
3) More severe case, if removing one printk statement in
bulk_in_complete(), USB gadget device cannot be recognised by host.
Thanks,
victor
static int kagen2_ep_queue(struct usb_ep *ep,
struct usb_request *req, gfp_t gfp_flags)
{
struct kagen2_ep *ka_ep;
struct kagen2_request *ka_req;
struct kagen2 * dev;
unsigned phys;
int num, len, in;
ka_req = container_of(req, struct kagen2_request, req);
if (!req || !req-complete || !req-buf
|| !list_empty(ka_req-queue))
{
printk(exit A\n);
return -EINVAL;
}
ka_ep = container_of(ep, struct kagen2_ep, ep);
if (!ep || (!ka_ep-desc ka_ep-num != 0))
{
printk(exit B\n);
return -EINVAL;
}
dev = ka_ep-dev;
if (!dev || !dev-driver || dev-gadget.speed == USB_SPEED_UNKNOWN)
{
printk(exit C\n);
return -ESHUTDOWN;
}
num = ka_ep-desc-bEndpointAddress USB_ENDPOINT_NUMBER_MASK;
in = (ka_ep-desc-bEndpointAddress USB_DIR_IN) != 0;
phys = (unsigned)req-buf;
len = req-length;
printk(KERN_DEBUG ept%d %s queue len 0x%x, buffer 0x%x\n,
num, in ? in : out, len, phys);
/* ep0 IN endpoint */
if ((len 0) (num == 0) (in != 0))
{
req-actual = 0;
ep0_in(phys, len, dev);
req-actual += len;
req-complete(ep, req);
list_del_init(ka_req-queue);
return 0;
}
/* ep1 IN endpoint */
else if ((len = 0) (num == 1) (in != 0))
{
req-actual = 0;
ep1_in(phys, len, dev);
req-actual += len;
req-complete(ep, req);
list_del_init(ka_req-queue);
return 0;
}
/* ep1 OUT endpoint */
else if (in == 0)
{
// read from EP1 OUT buffer
if (num == 1)
{
unsigned int val;
unsigned int val_arr[8];
int i;
// get byte count from hardware
val = readl(dev-base_addr + 0x008);
len = val 0xFF;
// read from hardware fifo1 data
for (i = 0; i len/4; i++)
{
val_arr[i] = readl(dev-base_addr + 0x084);
}
list_add_tail(ka_req-queue, ka_ep-queue);
ka_req-req.actual = len;
memcpy(ka_req-req.buf, val_arr[0], len);
ka_req-req.complete(ka_ep-ep, ka_req-req);
list_del_init(ka_req-queue);
// clear hardware OUT1CS register
val = readl(dev-base_addr + 0x008);
val = 0x00ff;
writel(val, dev-base_addr + 0x008);
}
}
return 0;
}
Re: Linux USB file storage gadget with new UDC
Hi,
I change that in UDC driver queue function, adding in a length check:
if (len 0)
{
ka_req-req.complete(ka_ep-ep,
ka_req-req);
list_del_init(ka_req-queue);
}
What is len? Is it the packet size? If it is then this check is
wrong, because the UDC driver must accept zero-length packets.
Yes, it is packet size. So UDC driver must accept zero-length packets
sent from USB host?
Just before the line that calls ka_req-req.complete, add:
WARN_ON(!victor_test);
victor_test = 0;
Then you'll get a stack dump every time the completion routine is
called without an interrupt occurring first. The stack dump will help
you to figure out why this is going wrong and where the problem is.
This is the stack dump when the completion routine is called without
an interrupt occurring first, is it useful?
Backtrace:
[c020c0fc] (dump_backtrace+0x0/0x110) from [c03ef5e4] (dump_stack+0x18/0x1c)
r6:bf030da8 r5:c12aec00 r4:c12b4c00 r3:00f8
[c03ef5cc] (dump_stack+0x0/0x1c) from [bf02fecc]
(kagen2_ep_queue+0x520/0x598 [kagen2_udc])
[bf02f9ac] (kagen2_ep_queue+0x0/0x598 [kagen2_udc]) from
[bf036068] (fsg_lun_open+0x578/0x1278 [g_file_storage])
[bf035f20] (fsg_lun_open+0x430/0x1278 [g_file_storage]) from
[bf037cd4] (fsg_main_thread+0x10c/0x155c [g_file_storage])
r8: r7:0001 r6:c12896c0 r5:c12896bc r4:c1289600
[bf037bc8] (fsg_main_thread+0x0/0x155c [g_file_storage]) from
[c022f8f4] (kthread+0x94/0xa0)
[c022f860] (kthread+0x0/0xa0) from [c02191c8] (do_exit+0x0/0x6f0)
r6:c02191c8 r5:c022f860 r4:c1327e00
Here's an example. This shows the port status immediately after the
first port reset in the April 22 usbmon trace:
f2f4f740 1985276053 S Ci:2:002:0 s a3 00 0004 0004 4
f2f4f740 1985276154 C Ci:2:002:0 0 4 = 03011000
The 01 in the second byte of the response indicates full speed. If
the connection were high speed, the second byte would be 05. See
Section 11.24.2.7 in the USB-2.0 specification, and especially the
description of bit 10 in Table 11-21 and 11.24.2.7.1.8.
Thanks, i found the bit 10 in Table 11-21 Port Status Field.
0 = Full-speed device attached to this port.
1 = High-speed device attached to this port.
victor
--
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
Re: Linux USB file storage gadget with new UDC
On Wed, 24 Apr 2013, victor yeo wrote:
Hi,
I change that in UDC driver queue function, adding in a length check:
if (len 0)
{
ka_req-req.complete(ka_ep-ep,
ka_req-req);
list_del_init(ka_req-queue);
}
What is len? Is it the packet size? If it is then this check is
wrong, because the UDC driver must accept zero-length packets.
Yes, it is packet size. So UDC driver must accept zero-length packets
sent from USB host?
Yes, it must.
This is the stack dump when the completion routine is called without
an interrupt occurring first, is it useful?
Backtrace:
[c020c0fc] (dump_backtrace+0x0/0x110) from [c03ef5e4]
(dump_stack+0x18/0x1c)
r6:bf030da8 r5:c12aec00 r4:c12b4c00 r3:00f8
[c03ef5cc] (dump_stack+0x0/0x1c) from [bf02fecc]
(kagen2_ep_queue+0x520/0x598 [kagen2_udc])
[bf02f9ac] (kagen2_ep_queue+0x0/0x598 [kagen2_udc]) from
[bf036068] (fsg_lun_open+0x578/0x1278 [g_file_storage])
[bf035f20] (fsg_lun_open+0x430/0x1278 [g_file_storage]) from
[bf037cd4] (fsg_main_thread+0x10c/0x155c [g_file_storage])
r8: r7:0001 r6:c12896c0 r5:c12896bc r4:c1289600
[bf037bc8] (fsg_main_thread+0x0/0x155c [g_file_storage]) from
[c022f8f4] (kthread+0x94/0xa0)
[c022f860] (kthread+0x0/0xa0) from [c02191c8] (do_exit+0x0/0x6f0)
r6:c02191c8 r5:c022f860 r4:c1327e00
This shows that kagen2_ep_queue() calls kareq-req.complete. Perhaps
indirectly, through another function. If this is true then it's
probably a bug. You should check it out.
On the other hand, it also shows that fsg_lun_open() calls
kagen2_ep_queue() -- again, perhaps indirectly. That isn't right.
So you may need to do more exploring. Add printk statements to a bunch
of places in the UDC driver so you can follow the flow of control.
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
