On Thu, 2015-04-09 at 11:07 -0400, Alan Stern wrote: > On Thu, 9 Apr 2015, Hans de Goede wrote: > > > > uas.c was patched (see attached), the quirk line was temporarily removed > > > > Thanks for testing this. > > > > > and i now have access to the drive using xhci and uas. usbmon trace is > > > attached. > > > > What exactly do you mean with "i now have access to the drive using xhci and uas" ? > > Do you mean that everything works correctly with xhci + uas when setting > > .max_sectors = 240 ? > > Yes, that's what Steve meant. Without the .max_sectors = 240 > restriction, the device froze up when the kernel tried to perform a > transfer that was too large (around 190 KB). > > > Alan, any ideas on how to move forward with this, I do not want to limit all > > uas devices to .max_sectors = 240, I can whip up a patch to set max_sectors = 240 > > on the ASM1053 but not the ASM1153. > > Some sort of quirk definitely seems like the right thing to do. Given > the peculiarities of this device family, the quirk probably has to be > implemented in code (as opposed to a static table à la > unusual_devs.h). > Still, I can imagine the uas-detect.h code setting the > US_FL_MAX_SECTORS_64 flags bit and then the uas driver calling > blk_queue_max_hw_sectors() the way we do in > scsiglue.c:slave_configure(). Alan, would this approach create/implement dynamic max sector values that might optimize speed/performance of the drive(s) transfer speeds? The reason i ask is that the performance of the drive seems slow and there were intermittent hangs during transfers based on my limited use of the drive so far. Steve > > Alan Stern > > -- -- 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
