On Tue, 23 Apr 2013, victor yeo wrote:
> Hi,
>
> >> Here is a full log from the beginning which shows another problem.
> >> When the SCSI_READ_10 command below is received, there is a disconnect
> >> or port reset which causes the (-32) broken pipe problem.
> >
> > You really need to fix the old problems before worrying about new
> > problems. The set_halt still isn't working, and the UDC continues to
> > continues to call bulk_out_complete multiple times without receiving
> > any packets.
>
> 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.
> However, i still observe the SCSI command being received by UDC and
> gadget driver, but not processed by gadget driver.
You need to figure out why this code is getting called at the wrong
time. Here's one way to do it.
In your UDC driver, add a new global variable outside of any function:
static int victor_test;
In the interrupt handler, add a line that does:
victor_test = 1;
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.
> For the UDC and gadget driver log, it looks like the flow cannot get
> past get_next_command() of fsg_main_thread(). The log is attached.
>
> [start_transfer] 43425355 9
> ept1 out queue len 0x200, buffer 0xc1338000
> g_file_storage gadget: bulk-out, length 31:
> 00000000: 55 53 42 43 09 00 00 00 00 00 00 00 00 00 06 00
> 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 f8 7e 34
> g_file_storage gadget: get_next_command
>
> The same SCSI command as seen on usbmon log:
>
> f2f4fe40 3842078083 S Bo:2:050:1 -115 31 = 55534243 09000000 00000000
> 00000600 00000000 00000000 00000000 000000
This does not look like the same command. The last three bytes are
different: "f8 7e 34" as opposed to "00 00 00".
> > It would be easier to maintain a stable link if the UDC connected at
> > high speed in the first place. The usbmon log shows that the
> > connection was at full speed (12 Mb/s), not high speed (480 Mb/s) --
> > which means that this line:
> >
> >> g_file_storage gadget: high-speed config #1
> >
> > in the gadget log indicates another bug in the UDC driver. It told the
> > gadget driver that the connection was high speed, but the connection
> > really was full speed.
>
> How to read from usbmon log that the connection was at full speed?
The port status data from the hub that the gadget is plugged into
contains a lot of information, including the speed of the connection.
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 0000 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.
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
