* Sebastian Andrzej Siewior | 2011-12-16 15:47:24 [+0100]: >>If you want to take a stab at redoing your patch #2 to use only one >>status URB for USB 2.0 devices, I would appreciate it. Then I can build >>the abort/reset synchronization on top of it. >Okay. Just once things started to become easy.... So while I tried to have only one status urb which I always re-submit (as Matthew/ You suggested) I run into the problem that I don't have struct scsi_device yet. So I just created a device with two luns to see if this struct happens always to be same. Ofcourse it is not. So if we re-submit the one status URB over and over again, we have to get the device right. The only thing that we have left to get our device in the status complete callback is the tag number which means we need a reverse lookup for that. To make it little more fun, those two devices have their own request queue so we can't use a 1:1 queue slot <-> tag number mapping because we have to distinguish between tag 0 for lun0 and tag 0 for lun1. I admit now that it was a bad idea to test lun support on high speed. The good news is that it worked on SS :) | scsi0 : uas | usbcore: registered new interface driver uas | scsi 0:0:0:0: Direct-Access LIO-ORG RAMDISK-MCP 4.0 PQ: 0 ANSI: 5 | scsi 0:0:0:1: Direct-Access LIO-ORG FILEIO 4.0 PQ: 0 ANSI: 5 | sd 0:0:0:0: [sda] 262144 512-byte logical blocks: (134 MB/128 MiB) | sd 0:0:0:1: [sdb] 61441 512-byte logical blocks: (31.4 MB/30.0 MiB) | sd 0:0:0:0: [sda] Write Protect is off | sd 0:0:0:0: [sda] Mode Sense: 2f 00 00 00 | sd 0:0:0:1: [sdb] Write Protect is off | sd 0:0:0:1: [sdb] Mode Sense: 2f 00 00 00 | sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA | sd 0:0:0:1: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA | sda: unknown partition table | sdb: sdb1 | sd 0:0:0:1: [sdb] Attached SCSI disk | sd 0:0:0:0: [sda] Attached SCSI disk Going through to my log I saw that I have sometimes two requests with the same tag on both luns more or less at the same time. So on SS both requests are enqueued on the same stream with the same tag number. This works because they are processed in order. This is not wrong but it would be more efficient if we would enqueue them on two streams. So. Where do we start? What about this: Unique tag number => tag <-> device struct => one status urb for HS >>Sarah Sharp Sebastian -- 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
