Re: Regression - SATA disks behind USB ones on v4.8-rc1, breaking boot. [Re: Who reordered my disks (probably v4.8-rc1 problem)]

On 14 August 2016 at 11:10, Pavel Machek wrote: > > It is the case in v4.6. We had change hda->sda for SATA drives long > time ago, it was stable since that. Not for me. It has been like forever (even if it wasn't the fact) that the disk order is not consistent among boots. Only

Re: Regression - SATA disks behind USB ones on v4.8-rc1, breaking boot. [Re: Who reordered my disks (probably v4.8-rc1 problem)]

disks from the latter. Sociopaths like me that put the root filesystem on an UAS drive should really be ignored. Wait, there's NVMe! Problem solved. On 14 August 2016 at 10:26, David Lang <da...@lang.hm> wrote: > On Sun, 14 Aug 2016, Tom Yan wrote: > >> On 14 August 2016 at 18:

Re: Regression - SATA disks behind USB ones on v4.8-rc1, breaking boot. [Re: Who reordered my disks (probably v4.8-rc1 problem)]

On 14 August 2016 at 18:07, Tom Yan <tom.t...@gmail.com> wrote: > On 14 August 2016 at 18:01, Pavel Machek <pa...@ucw.cz> wrote: >> >> Since SATA support was merged, certainly since v2.4, and from way >> before /dev/disk/by-id existed. > > I have no i

Re: Regression - SATA disks behind USB ones on v4.8-rc1, breaking boot. [Re: Who reordered my disks (probably v4.8-rc1 problem)]

On 14 August 2016 at 18:01, Pavel Machek wrote: > > Since SATA support was merged, certainly since v2.4, and from way > before /dev/disk/by-id existed. I have no idea how "SATA before USB" had been done in the past (if it was ever a thing in the kernel), but that has not been the

Re: Regression - SATA disks behind USB ones on v4.8-rc1, breaking boot. [Re: Who reordered my disks (probably v4.8-rc1 problem)]

Since when it is expected that SATA disks will always be probed before USB disks? We can't guarantee that even if we make sure all ata drivers are loaded before usb-storage/uas. That's why we need consistent namings (e.g. /dev/disk/by-id/*). On 14 August 2016 at 17:20, Pavel Machek

Re: [PATCH] USB: uas: Fix slave queue_depth not being set

mmit sets to the same value. >>>>> >>>>> This is incorrect, without the scsi_change_queue_depth() call the >>>>> slave's queue_depth defaults to 1, introducing a performance >>>>> regression. >>>>> >>>>> This commi

[uas/scsi] untagged commands?

In this commit: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/usb/storage/uas.c?id=198de51dbc3454d95b015ca0a055b673f85f01bb There is the following comment: > 1 tag is reserved for untagged commands So my question is, what exactly are "untagged commands"? If we

Re: [PATCH] USB: uas: Fix slave queue_depth not being set

On 24 May 2016 at 01:36, James Bottomley wrote: > > Are you sure about this? For spinning rust, experiments imply that the > optimal queue depth per device is somewhere between 2 and 4. Obviously > that's not true for SSDs, so it depends on your use case.

Re: [PATCH 1/1] uas: leave can_queue as MAX_CMNDS if device reports larger qdepth

that simply has `.can_queue = MAX_CMNDS` in the host template removed? On 24 May 2016 at 01:27, James Bottomley <james.bottom...@hansenpartnership.com> wrote: > On Tue, 2016-05-24 at 01:23 +0800, Tom Yan wrote: >> Nothing wrong. It's just .can_queue = MAX_CMNDS in the host template

Re: [PATCH 1/1] uas: leave can_queue as MAX_CMNDS if device reports larger qdepth

ore then MAX_CMNDS...") On 24 May 2016 at 01:00, Greg KH <gre...@linuxfoundation.org> wrote: > On Tue, May 24, 2016 at 12:02:43AM +0800, tom.t...@gmail.com wrote: >> From: Tom Yan <tom.t...@gmail.com> >> >> Commit 198de51dbc34 ("USB: uas: Limit qdepth at th

Re: [regression] uas no longer queues commands since v4.5.2

Btw, I suppose `.can_queue = MAX_CMNDS` in the host template is unnecessary (unless we are going to revert `shost->can_queue = devinfo->qdepth - 2`)? On 22 May 2016 at 18:39, Tom Yan <tom.t...@gmail.com> wrote: > With commit 198de51dbc3454d95b015ca0a055b673f85f01bb, uas

[regression] uas no longer queues commands since v4.5.2

With commit 198de51dbc3454d95b015ca0a055b673f85f01bb, uas no longer set `queue_depth` with scsi_change_queue_depth(), so now `queue_depth` of UAS drives are 1. Even though `can_queue` is set to `devinfo->qdepth - 2`, but apparently that does not help, since I can see performance impact. Suppose

Re: BUG: broken support on discard (max_discard_bytes) with uas

OT driver). If it's lower than that (e.g. 2 times - 7 times), it seems some queued UNMAP commands are rejected by my device, but the xhci_hcd error will not be triggered. On 12 March 2016 at 09:41, Tom Yan <tom.t...@gmail.com> wrote: > So I have a USB-SATA bridge that supports translating

Re: [PATCH 1/1] sd: do not let LBPME bit stop the VPDs speak

On 10 March 2016 at 12:36, Tom Yan <tom.t...@gmail.com> wrote: > > Both `blkdiscard` with a patched kernel and `sg_unmap` appeared to > have gone well (checked with `hexdump`). > Actually, `blkdiscard` didn't quite actually go well. It seems last time it just ended quick

Re: Data loss with usb dvb tuners that is fixed by spinning a cpu - how to debug?

Not sure if it's relevant at all, but Iong time ago I had a pci-e dtv tuner which requires c-state to be disabled in BIOS (workaround officially suggested by its vendor) to work. On 1 July 2015 at 20:01, Andy Furniss adf.li...@gmail.com wrote: Andy Furniss wrote: Andy Furniss wrote: Hi I

Re: optimal io size / custom alignment

2015 at 05:01, Martin K. Petersen martin.peter...@oracle.com wrote: Tom == Tom Yan tom.t...@gmail.com writes: Tom No I put it in the wrong way. What I meant was sd vs md. For Tom example, couldn't the scsi disk driver bind the value it reads from Tom the VPD to another variable instead of optimal

Re: optimal io size / custom alignment

On 17 June 2015 at 05:28, Martin K. Petersen martin.peter...@oracle.com wrote: There are plenty of SSDs that report 4K physical sectors, fwiw. Oh didn't know that. Wonder if it's yet another garbage info. Though 4k is often a nice value to make use of. We gave up on USB-SATA bridges long ago.

Re: TRIM/DISCARD for usb drives?

sd_config_discard(). On 15 June 2015 at 22:37, Alan Stern st...@rowland.harvard.edu wrote: On Mon, 15 Jun 2015, Tom Yan wrote: I have a SanDisk Extreme USB Flash Drive (http://www.sandisk.com/products/usb/drives/extreme/), which does NOT support UASP so is running under usb-storage. According to `hdparm

Re: optimal io size / custom alignment

: Tom == Tom Yan tom.t...@gmail.com writes: Tom From the adapter/drive I have, it is the same as the Maximum Tom transfer length and they seem to be simply limits of SCSI WRITE Tom SAME (10/16) command: The two values have nothing to do with each other. They just happen to be the same in your

Re: questions about uas

So I did some further investigation on the weird optimal i/o size I got from my usb3/sata adapter/ssd, started by grep'ing the size in the /sys/block/sdx/queue: [tom@localhost ~]$ grep 33553920 /sys/block/sdb/queue/* grep: /sys/block/sdb/queue/iosched: Is a directory

TRIM/DISCARD for usb drives?

I have a SanDisk Extreme USB Flash Drive (http://www.sandisk.com/products/usb/drives/extreme/), which does NOT support UASP so is running under usb-storage. According to `hdparm`, it seems to supports TRIM; and according to `sg3_opcodes`, it seems to support ATA Pass-Through (12/16). However, all

questions about uas

Hi all! I have the following adapter: http://www.startech.com/HDD/Adapters/USB-3-SATA-adapter-cable-with-UASP~USB3S2SAT3CB which I am using it for: http://ark.intel.com/products/56604/Intel-SSD-X25-M-Series-80GB-2_5in-SATA-3Gbs-50nm-MLC and I can see in `lsusb`: Bus 002 Device 004: ID 174c:55aa

Re: default value of power/wakeup

(sounds outrageous doesn't it). Hope that something will be done for this one day anyway. On 23 April 2015 at 22:40, Alan Stern st...@rowland.harvard.edu wrote: On Thu, 23 Apr 2015, Tom Yan wrote: I'm not saying that the kernel shouldn't initialize the attributes or have a default. But it should

Re: default value of power/wakeup

https://bugs.freedesktop.org/show_bug.cgi?id=90041 Because udev's work would get overrided if there's further manipulation. So if you want your udev rule to work, you have to make sure you run a trigger command after the module is loaded or reloaded. This would happen for all types of devices if

Re: default value of power/wakeup

I'm not saying that the kernel shouldn't initialize the attributes or have a default. But it should only set the default when the attribute is initialized (It doesn't even matter to me whether it's enabled or disabled). It's just there should not be further manipulation from the kernel (e.g.

Re: default value of power/wakeup

On 21 April 2015 at 23:51, Alan Stern st...@rowland.harvard.edu wrote: Anyway, you're suggesting that drivers should never override sysfs attribute values. But there doesn't seem to be any other way to implement the kernel's policy that wakeup should be enabled by default for all keyboard

Re: default value of power/wakeup

default should be avoid from all drivers until it is really necessary, and when it is needed, it's best to have the default set right at the point when the attribute is initialized if possible. On 21 April 2015 at 05:20, Tom Yan tom.t...@gmail.com wrote: On 21 April 2015 at 03:44, Alan Stern st

Re: default value of power/wakeup

On 21 April 2015 at 03:44, Alan Stern st...@rowland.harvard.edu wrote: The generic driver includes code for enabling wakeup by default, Is there a part of code which can shows this? It seems to me that the usbhid module is loaded for all USB HID devices, so I doubt a bit: [tom@localhost ~]$

default value of power/wakeup

I have the following two USB wireless mouse/keyboard receivers: logitech-djreceiver 0003:046D:C52B.0003: hiddev0,hidraw0: USB HID v1.11 Device [Logitech USB Receiver] on usb-:00:14.0-13/input2 hid-generic 0003:046D:C52E.0005: input,hidraw2: USB HID v1.11 Keyboard [Logitech USB Receiver] on

Re: default value of power/wakeup

--- wMaxPacketSize 0x0014 1x 20 bytes On 21 April 2015 at 01:41, Alan Stern st...@rowland.harvard.edu wrote: On Tue, 21 Apr 2015, Tom Yan wrote: I have the following two USB wireless mouse/keyboard receivers: logitech-djreceiver 0003:046D:C52B.0003: hiddev0,hidraw0: USB HID v1.11 Device

Re: default value of power/wakeup

debug descriptor: Resource temporarily unavailable Device Status: 0x (Bus Powered) On 21 April 2015 at 03:08, Alan Stern st...@rowland.harvard.edu wrote: On Tue, 21 Apr 2015, Tom Yan wrote: Thank you very much for your reply. So I tried to see if there's any difference between

Re: USB devices cannot be be allocated / assigned slot (xhci_hcd)

if the two issues are related (they don't seem to co-occur anyway). I tell about it just in case there is a general problem in udev or so causing these. On 7 April 2015 at 19:02, Greg KH g...@kroah.com wrote: Note, vger.kernel.org rejects html email On Tue, Apr 07, 2015 at 04:50:59PM +0800, Tom Yan

USB devices cannot be be allocated / assigned slot (xhci_hcd)

The following error comes up frequently and some USB device fail to show up after boot: xhci_hcd :00:14.0: Error while assigning device slot ID xhci_hcd :00:14.0: Max number of devices this xHCI host supports is 32. usb usb1-port13: couldn't allocate usb_device It happens randomly among