Re: [usb-storage] Re: Make UAS work on HS for devices with and without command tagging support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



* 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-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]
  Powered by Linux