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 that would
logica
ore enumerating 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 wrote:
> On Sun, 14 Aug 2016, Tom Yan wrote:
>
>> On 14 August 2016 at 18:07, Tom
On 14 August 2016 at 18:07, Tom Yan wrote:
> 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
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 case since
at le
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 wrote:
> Hi!
>
t;>>
>>>>> This is incorrect, without the scsi_change_queue_depth() call the
>>>>> slave's queue_depth defaults to 1, introducing a performance
>>>>> regression.
>>>>>
>>>>> This commit restores the call, fixing th
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 ne
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.
Are we supposed to care about the stora
patch that simply has `.can_queue =
MAX_CMNDS` in the host template removed?
On 24 May 2016 at 01:27, James Bottomley
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
>> is no longer neceesary, since
eue
more then MAX_CMNDS...")
On 24 May 2016 at 01:00, Greg KH wrote:
> On Tue, May 24, 2016 at 12:02:43AM +0800, tom.t...@gmail.com wrote:
>> From: Tom Yan
>>
>> Commit 198de51dbc34 ("USB: uas: Limit qdepth at the scsi-host level") made
>> qde
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 wrote:
> With commit 198de51dbc3454d95b015ca0a055b673f85f01bb, uas no longer
> set `queue
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 li
the BOT 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 wrote:
> So I have a USB-SATA bridge that supports translating SCSI UNMAP to
>
On 10 March 2016 at 12:36, Tom Yan 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 quickly with only error on kern
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 wrote:
> Andy Furniss wrote:
>>
>> Andy Furniss wrote:
>>>
>>> Hi I recently set
k that vendors would do better on VPDs in the
future.
On 19 June 2015 at 05:01, Martin K. Petersen wrote:
>>>>>> "Tom" == Tom Yan writes:
>
> Tom> No I put it in the wrong way. What I meant was "sd vs md". For
> Tom> example, couldn't the s
On 17 June 2015 at 05:28, Martin K. Petersen 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. Their designers appear to
y too idealistic especially when it seems that this issue
mostly happens on USB bridges. I am not even sure if the SCSI
standards has anything to say about this practice.
> Failing that, adjust your partitions manually.
Yeah that's why I said fdisk should allow custom alignment.
On 1
sd_config_discard().
On 15 June 2015 at 22:37, Alan Stern 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".
>&g
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,
al
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
/sys/block/sdb/queue/optimal_i
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
no-op (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 wrote:
> On Thu, 23 Apr 2015, Tom Yan wrote:
>
>> I'm not saying that the kernel shouldn't initialize the attributes or
>> have
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 th
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. devic
On 21 April 2015 at 23:51, Alan Stern 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 devices.
I just doubt if
s
of udev, but I don't see the point of doing so. IMHO these hard-coded
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:2
On 21 April 2015 at 03:44, Alan Stern 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 ~]$ journalctl -b -1 | grep hid
lable
can't get debug descriptor: Resource temporarily unavailable
Device Status: 0x
(Bus Powered)
On 21 April 2015 at 03:08, Alan Stern wrote:
> On Tue, 21 Apr 2015, Tom Yan wrote:
>
>> Thank you very much for your reply.
>>
>> So I tried to see if there
bmAttributes3
< Transfer TypeInterrupt
< Synch Type None
< Usage Type Data
< wMaxPacketSize 0x0020 1x 32 bytes
---
> wMaxPacketSize 0x0014 1x 20 bytes
On 21 April 2015 at 01:41, A
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 usb
at all with the other
receiver.
I'm not sure 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 wrote:
>
>
> On Tue, Apr 07, 2015
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 b
33 matches
Mail list logo
