On Mon, Apr 12, 2010 at 04:18:27PM -0400, Alan Stern wrote: > On Mon, 12 Apr 2010, Sarah Sharp wrote: > > > On Sun, Apr 11, 2010 at 02:42:29PM -0400, Alan Stern wrote: > > > On Sun, 11 Apr 2010, Ramya Desai wrote: > > > > > > > According to her, she saw ~120 entries when I change the max_sectors > > > > value to 960 or 1024 in the scsi_host_template. I want to say one > > > > thing here that I am testing the default usb storage driver for 960 or > > > > 1024 sectors with my UASP device.When I am testing the default usb > > > > storage driver with 960 max_sectors Sarah saw ~120 scatter-gather list > > > > entries. > > > > > > > Please let me know if you need any additional information. > > > > > > Please run some more tests. Can you or Sarah verify that xhci-hcd > > > receives a request with more than 63 scatterlist elements when the > > > sg_tablesize value is 63? The value of max_sectors doesn't matter. > > > > In the tests I ran with the mass storage driver, setting max_sectors > > didn't matter, I always only got an sglist of no more than 63 TRBs (or > > 120 if I doubled the TRBS_PER_SEGMENT to 128). The four patches I > > tested with are on my xhci-large-tx branch if anyone is interested. > > > > I never saw the mass storage driver enqueue more sg entries than > > TRBS_PER_SEGMENT. It's just Ramya's driver that has this behavior. At > > this point, we can't tell what he's doing without his source code. > > This directly contradicts Ramya's statement above: "When I am testing > the default usb storage driver with 960 max_sectors Sarah saw ~120 > scatter-gather list entries." I started this thread because I wanted to know why I wasn't seeing sg lists with more than 63 entries, even when I added another segment to the ring. Ramya is confused. With the four patches on the xhci-large-tx branch, if I execute the following command over the log file to see the number of sglist entries: grep "sglist used, num_trbs" logfile I see output like this: Mar 30 16:05:35 xanatos kernel: [ 7555.652954] usb 9-2: ep 0x81 - urb len = 4096, sglist used, num_trbs = 1 Mar 30 16:05:35 xanatos kernel: [ 7555.653624] usb 9-2: ep 0x81 - urb len = 40960, sglist used, num_trbs = 10 Mar 30 16:05:35 xanatos kernel: [ 7555.655015] usb 9-2: ep 0x81 - urb len = 4096, sglist used, num_trbs = 1 Mar 30 16:05:35 xanatos kernel: [ 7555.656090] usb 9-2: ep 0x81 - urb len = 98304, sglist used, num_trbs = 24 Mar 30 16:05:35 xanatos kernel: [ 7555.658527] usb 9-2: ep 0x81 - urb len = 131072, sglist used, num_trbs = 32 ... Mar 30 16:06:04 xanatos kernel: [ 7584.521944] usb 9-2: ep 0x2 - urb len = 258048, sglist used, num_trbs = 63 Mar 30 16:06:04 xanatos kernel: [ 7584.526164] usb 9-2: ep 0x2 - urb len = 262144, sglist used, num_trbs = 63 Mar 30 16:06:04 xanatos kernel: [ 7584.908560] usb 9-2: ep 0x2 - urb len = 262144, sglist used, num_trbs = 40 Mar 30 16:06:04 xanatos kernel: [ 7584.912421] usb 9-2: ep 0x2 - urb len = 200704, sglist used, num_trbs = 47 Mar 30 16:06:05 xanatos kernel: [ 7585.169404] usb 9-2: ep 0x2 - urb len = 4096, sglist used, num_trbs = 1 Mar 30 16:06:05 xanatos kernel: [ 7585.222138] usb 9-2: ep 0x2 - urb len = 262144, sglist used, num_trbs = 53 Mar 30 16:06:05 xanatos kernel: [ 7585.225944] usb 9-2: ep 0x2 - urb len = 262144, sglist used, num_trbs = 49 Mar 30 16:06:05 xanatos kernel: [ 7585.946910] usb 9-2: ep 0x2 - urb len = 262144, sglist used, num_trbs = 27 If I grep for number of TRBs in double digits greater than 63 with grep "sglist used, num_trbs = [6-9].*[4-9].*" logfile and grep "sglist used, num_trbs = [7-9].*[0-9].* I get nothing. Meaning I never saw an sglist with more than 63 entries when (TRBS_PER_SEGMENT - 1) was 63, even though there were two segments on the ring. > Evidently the two of you need to figure out exactly what happened. > More tests can't hurt... I can't reproduce Ramya's ring wrapping issue with the standard mass storage drivers. If Ramya can send patches against the driver and USB core to reproduce this, then I can help. Sarah Sharp -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
