subject:"uas failing on multiple disk access on a jmicron JMS567 bridge"

Re: uas failing on multiple disk access on a jmicron JMS567 bridge

2018-02-06 Thread Menion

2018-02-06 11:18 GMT+01:00 Oliver Neukum :
> Am Mittwoch, den 31.01.2018, 12:45 +0100 schrieb Menion:
>> you can see that short while after the two HD are mounted I start to
>> get any sort of USB command errors.
>
> Well, no, all errors are Write(10). Thus my question whether you can
> trigger it with any other command. Does it error out with Read(10),
> too?
>
> Regards
> Oliver
>

No
As said the problems start when there are multiple write operation
This is a multi bay enclosure. If there is only one HDD inside, there
are no problems
Unfortunately it is not simple to "silence" the activity on the HDD,
since I run BTRFS on it.
That is why I have asked also for a way to provide more info. If you
google a little bit you will see that it is a very common problem
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: uas failing on multiple disk access on a jmicron JMS567 bridge

2018-02-06 Thread Oliver Neukum

Am Mittwoch, den 31.01.2018, 12:45 +0100 schrieb Menion:
> you can see that short while after the two HD are mounted I start to
> get any sort of USB command errors.

Well, no, all errors are Write(10). Thus my question whether you can
trigger it with any other command. Does it error out with Read(10),
too?

Regards
Oliver

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: uas failing on multiple disk access on a jmicron JMS567 bridge

2018-01-31 Thread Menion

Hello
Actually the mentioned ones are the very first synthomps that
something is going wrong:

Jan 27 08:56:06 Menionubuntu systemd[1]:
dev-disk-by\x2duuid-ba1e0d88\x2d2e26\x2d499d\x2d8fe3\x2d458b9c53349a.device:
Dev dev-disk-by\x2duuid-ba1e0d88\x2d2e26\x2d499d\x2d8fe3\x2d458b9c53349a.device
appeared twice wi$
Jan 27 08:56:06 Menionubuntu systemd[2308]:
dev-disk-by\x2duuid-ba1e0d88\x2d2e26\x2d499d\x2d8fe3\x2d458b9c53349a.device:
Dev dev-disk-by\x2duuid-ba1e0d88\x2d2e26\x2d499d\x2d8fe3\x2d458b9c53349a.device
appeared twice$
Jan 27 08:57:31 Menionubuntu systemd[1]: Started Session 6 of user menion.
Jan 27 08:57:54 Menionubuntu kernel: [  631.779771] sd 0:0:0:1: [sdb]
tag#1 uas_eh_abort_handler 0 uas-tag 2 inflight: CMD OUT
Jan 27 08:57:54 Menionubuntu kernel: [  631.779792] sd 0:0:0:1: [sdb]
tag#1 CDB: Write(10) 2a 00 00 35 ca 70 00 04 00 00
Jan 27 08:57:54 Menionubuntu kernel: [  631.780155] sd 0:0:0:1: [sdb]
tag#14 uas_eh_abort_handler 0 uas-tag 15 inflight: CMD OUT
Jan 27 08:57:54 Menionubuntu kernel: [  631.780173] sd 0:0:0:1: [sdb]
tag#14 CDB: Write(10) 2a 00 00 35 c6 70 00 04 00 00
Jan 27 08:57:54 Menionubuntu kernel: [  631.783903] sd 0:0:0:1: [sdb]
tag#13 uas_eh_abort_handler 0 uas-tag 14 inflight: CMD OUT
Jan 27 08:57:54 Menionubuntu kernel: [  631.783920] sd 0:0:0:1: [sdb]
tag#13 CDB: Write(10) 2a 00 00 35 c2 70 00 04 00 00
Jan 27 08:57:54 Menionubuntu kernel: [  631.787408] sd 0:0:0:1: [sdb]
tag#12 uas_eh_abort_handler 0 uas-tag 13 inflight: CMD OUT
Jan 27 08:57:54 Menionubuntu kernel: [  631.787429] sd 0:0:0:1: [sdb]
tag#12 CDB: Write(10) 2a 00 00 35 be 70 00 04 00 00
Jan 27 08:57:54 Menionubuntu kernel: [  631.791055] sd 0:0:0:1: [sdb]
tag#0 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD OUT
Jan 27 08:57:54 Menionubuntu kernel: [  631.791076] sd 0:0:0:1: [sdb]
tag#0 CDB: Write(10) 2a 00 00 35 ba 70 00 04 00 00
Jan 27 08:57:54 Menionubuntu kernel: [  631.795040] sd 0:0:0:1: [sdb]
tag#11 uas_eh_abort_handler 0 uas-tag 12 inflight: CMD OUT
Jan 27 08:57:54 Menionubuntu kernel: [  631.795062] sd 0:0:0:1: [sdb]
tag#11 CDB: Write(10) 2a 00 00 35 b6 70 00 04 00 00
Jan 27 08:57:54 Menionubuntu kernel: [  631.797905] sd 0:0:0:1: [sdb]
tag#10 uas_eh_abort_handler 0 uas-tag 11 inflight: CMD OUT
Jan 27 08:57:54 Menionubuntu kernel: [  631.797925] sd 0:0:0:1: [sdb]
tag#10 CDB: Write(10) 2a 00 00 35 b2 70 00 04 00 00
Jan 27 08:57:54 Menionubuntu kernel: [  631.801819] sd 0:0:0:1: [sdb]
tag#9 uas_eh_abort_handler 0 uas-tag 10 inflight: CMD OUT
Jan 27 08:57:54 Menionubuntu kernel: [  631.801838] sd 0:0:0:1: [sdb]
tag#9 CDB: Write(10) 2a 00 00 35 ae 70 00 04 00 00
Jan 27 08:57:54 Menionubuntu kernel: [  631.805521] sd 0:0:0:1: [sdb]
tag#8 uas_eh_abort_handler 0 uas-tag 9 inflight: CMD OUT
Jan 27 08:57:54 Menionubuntu kernel: [  631.805543] sd 0:0:0:1: [sdb]
tag#8 CDB: Write(10) 2a 00 00 35 aa 70 00 04 00 00
Jan 27 08:57:54 Menionubuntu kernel: [  631.808320] sd 0:0:0:1: [sdb]
tag#7 uas_eh_abort_handler 0 uas-tag 8 inflight: CMD OUT
Jan 27 08:57:54 Menionubuntu kernel: [  631.808338] sd 0:0:0:1: [sdb]
tag#7 CDB: Write(10) 2a 00 00 35 a6 70 00 04 00 00
Jan 27 08:57:54 Menionubuntu kernel: [  631.812207] sd 0:0:0:1: [sdb]
tag#6 uas_eh_abort_handler 0 uas-tag 7 inflight: CMD OUT
Jan 27 08:57:54 Menionubuntu kernel: [  631.812224] sd 0:0:0:1: [sdb]
tag#6 CDB: Write(10) 2a 00 00 35 a2 70 00 04 00 00
Jan 27 08:57:54 Menionubuntu kernel: [  631.815606] sd 0:0:0:1: [sdb]
tag#5 uas_eh_abort_handler 0 uas-tag 6 inflight: CMD OUT
Jan 27 08:57:54 Menionubuntu kernel: [  631.815623] sd 0:0:0:1: [sdb]
tag#5 CDB: Write(10) 2a 00 00 35 9e 70 00 04 00 00
Jan 27 08:57:54 Menionubuntu kernel: [  631.819379] sd 0:0:0:1: [sdb]
tag#4 uas_eh_abort_handler 0 uas-tag 5 inflight: CMD OUT
Jan 27 08:57:54 Menionubuntu kernel: [  631.819397] sd 0:0:0:1: [sdb]
tag#4 CDB: Write(10) 2a 00 00 35 9a 70 00 04 00 00
Jan 27 08:57:54 Menionubuntu kernel: [  631.823351] sd 0:0:0:1: [sdb]
tag#3 uas_eh_abort_handler 0 uas-tag 4 inflight: CMD OUT
Jan 27 08:57:54 Menionubuntu kernel: [  631.823372] sd 0:0:0:1: [sdb]
tag#3 CDB: Write(10) 2a 00 00 35 96 70 00 04 00 00
Jan 27 08:57:54 Menionubuntu kernel: [  631.826296] sd 0:0:0:1: [sdb]
tag#27 uas_eh_abort_handler 0 uas-tag 28 inflight: CMD OUT
Jan 27 08:57:54 Menionubuntu kernel: [  631.826317] sd 0:0:0:1: [sdb]
tag#27 CDB: Write(10) 2a 00 00 35 92 70 00 04 00 00

you can see that short while after the two HD are mounted I start to
get any sort of USB command errors. The enclosure can run 5 HDD, but
when I took the logs, only 2 HDD were mounted, so I think I can
exclude any kind of power supply issue also because in BOT mode I
didn't get any kind of problem 3 days of operation.
I cannot tell if the firmware is buggy, but it is a quite standard
40.16 Jlink firmware version. If you go to the mailing list logs, with
the same subject there is another user reporting the same problem
fixed by the same workaround (blacklist and use BOT mode)
Also, if you google a little bit around, there are a number of same

Re: uas failing on multiple disk access on a jmicron JMS567 bridge

2018-01-30 Thread Oliver Neukum

Am Montag, den 29.01.2018, 14:48 +0100 schrieb Menion:
> As soon as more than one HD in inserted in the enclosure, when
> parallel write operation are send to the HDs, you start to get
> immediately CMD error on UAS driver, after a while the USB gets in an
> inconsistent status and you are forced to reset.

Hi,

what is the first error you see?
If we can identify a specific command, we will be able
to do something about that. If it is a general reliability
issue the answer is more likely in the device's firmware.
And have you checked your power supply is adequate?

Regards
Oliver


--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

uas failing on multiple disk access on a jmicron JMS567 bridge

2018-01-29 Thread Menion

Hello
I am trying to follow up on the original thread, opened on this issue
by Christoph Gohle May 2017 (same email subject)
I confirm that the same issue is still present on kernel 4.14.15
(Mainline build for Ubuntu xenial, amd64)
My enclosure is an Orico 9558RU3, using JMS567 USB 3.0 to SATA bridge
together with JMB394 multiplexer with RAID
As soon as more than one HD in inserted in the enclosure, when
parallel write operation are send to the HDs, you start to get
immediately CMD error on UAS driver, after a while the USB gets in an
inconsistent status and you are forced to reset.

Jan 27 08:59:53 Menionubuntu kernel: [  750.564095] sd 0:0:0:1: [sdb]
tag#22 CDB: Write(10) 2a 00 00 5e fb 10 00 04 00 00
Jan 27 08:59:53 Menionubuntu kernel: [  750.567579] sd 0:0:0:1: [sdb]
tag#17 uas_eh_abort_handler 0 uas-tag 18 inflight: CMD OUT
Jan 27 08:59:53 Menionubuntu kernel: [  750.567604] sd 0:0:0:1: [sdb]
tag#17 CDB: Write(10) 2a 00 00 5e f7 10 00 04 00 00
Jan 27 08:59:53 Menionubuntu kernel: [  750.571280] sd 0:0:0:1: [sdb]
tag#16 uas_eh_abort_handler 0 uas-tag 17 inflight: CMD OUT
Jan 27 08:59:53 Menionubuntu kernel: [  750.571299] sd 0:0:0:1: [sdb]
tag#16 CDB: Write(10) 2a 00 00 5e f3 10 00 04 00 00
Jan 27 08:59:53 Menionubuntu kernel: [  750.575292] sd 0:0:0:1: [sdb]
tag#15 uas_eh_abort_handler 0 uas-tag 6 inflight: CMD OUT
Jan 27 08:59:53 Menionubuntu kernel: [  750.575304] sd 0:0:0:1: [sdb]
tag#15 CDB: Write(10) 2a 00 00 5e ef 10 00 04 00 00


With BTFS the things go even worst:

Jan 26 18:46:01 Menionubuntu kernel: [22961.078609] sd 0:0:0:0: [sda]
Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Jan 26 18:46:02 Menionubuntu kernel: [22961.160317] sd 0:0:0:0: [sda]
tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Jan 26 18:46:02 Menionubuntu kernel: [22961.160378] sd 0:0:0:0: [sda]
tag#0 Sense Key : Aborted Command [current]
Jan 26 18:46:02 Menionubuntu kernel: [22961.160523] sd 0:0:0:0: [sda]
tag#0 Add. Sense: No additional sense information
Jan 26 18:46:02 Menionubuntu kernel: [22961.160544] sd 0:0:0:0: [sda]
tag#0 CDB: Read(16) 88 00 00 00 00 00 00 00 00 00 00 00 00 08 00 00
Jan 26 18:46:02 Menionubuntu kernel: [22961.160558] print_req_error:
I/O error, dev sda, sector 0
Jan 26 18:46:02 Menionubuntu kernel: [22961.160597] Buffer I/O error
on dev sda, logical block 0, async page read
Jan 26 18:46:02 Menionubuntu kernel: [22961.244469] sd 0:0:0:0: [sda]
tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Jan 26 18:46:02 Menionubuntu kernel: [22961.244539] sd 0:0:0:0: [sda]
tag#0 Sense Key : Aborted Command [current]
Jan 26 18:46:02 Menionubuntu kernel: [22961.244556] sd 0:0:0:0: [sda]
tag#0 Add. Sense: No additional sense information
Jan 26 18:46:02 Menionubuntu kernel: [22961.244577] sd 0:0:0:0: [sda]
tag#0 CDB: Read(16) 88 00 00 00 00 00 00 00 00 00 00 00 00 08 00 00
Jan 26 18:46:02 Menionubuntu kernel: [22961.244590] print_req_error:
I/O error, dev sda, sector 0


Putting in UAS blacklist the device so running old BOT mode is a valid
workaround, the same enclosure with the same HDs run for days with no
USB error.
Due to the fact that I am running JBOD on BTRFS, I really need to run
in BOT mode, but I can try to provide some logs, if anyone is willing
to pick up the issue.
Bye
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: uas failing on multiple disk access on a jmicron JMS567 bridge

2017-05-29 Thread Christoph Gohle


> On 24 May 2017, at 21:40, Christoph Gohle  wrote:
> 
>> 
>>> On 22 May 2017, at 14:37, Mathias Nyman  
>>> wrote:
>>> 
>>> On 22.05.2017 11:48, Christoph Gohle wrote:
 Hey Mathias,
 
 
> On 19 May 2017, at 09:58, Mathias Nyman  
> wrote:
> 
>> 
> 
> 4.11 kernel has xhci traces enabled, could you try to reproduce it with 
> 4.11?
> xhci traces can be enabled with:
> 
> echo 1 > /sys/kernel/debug/tracing/events/xhci-hcd/enable
> 
> If you know how to reliably reproduce this then please enable tracing 
> just before
> triggering this. It generates a lot of data.
> 
> -Mathias
 I would be able to do xhci traces with a 4.10 kernel (4.10.0-21-generic 
 #23~16.04.1-Ubuntu SMP). Don’t really want to go to 4.11. . Still 
 interested?
>>> 
>>> xhci got more useful tracing support in 4.11,
>>> Sure, you can try if there's something in 4.10
> OK. Now I managed (had to update-initramfs, stupid…)
> 
… I decided to give up on this. It seems like neither usb-storage nor uas is 
really a reliable driver for this device. Even though usb-storage did not show 
the above errors in the log, in the end I found that storage access was not 
reliable.
hotplugging or unplugging a disk from the device did not work as expected: all 
disks were initialized again and recieved new device nodes. smartd got confused 
for some reason (disks changing their identification?).

Now i am using the eSATA interface provided by the device instead. That seems 
to work OK for a couple of days now and has not expressed any of the above 
symptoms.

Anyway, thanks for your help.
Christoph
--
Christoph Gohle
christ...@gohle.org








signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: uas failing on multiple disk access on a jmicron JMS567 bridge

2017-05-24 Thread Jack Coulter

Hi Christoph,

Out of curiosity, what exact device is this? I have an multi-disk JMS567
based enclosure which reports the same IDs from lsusb, doesn't work with
uas at all. According to the datasheet for JMS567 it should support UAS,
but I've received conflicting information from the manufacturer of my
enclosure stating JMS567 has issues with UAS when multiple disks are
involved, but further details weren't provided.


Cheers,
Jack

On 19/05/17 00:30, Christoph Gohle wrote:
> Hi,
>
> I have seen several reports around the internet regarding failing io on 
> USB-SATA bridges. However, these reports seem to be partially old and/or 
> fixes proposed are implemented in my kernel but don’t fix things. Therefore I 
> thought I report here again. If this is know/duplicate please apologise.
>
> I am running on ubuntu 16.04 LTS with kernel
>
> $ ~> uname -a
> Linux gserv 4.8.0-52-generic #55~16.04.1-Ubuntu SMP Fri Apr 28 14:36:29 UTC 
> 2017 x86_64 x86_64 x86_64 GNU/Linux
>
> I was also using the 4.4.0-75-generic version of the kernel before, with same 
> results. I am having a JMS567 bridge with (currently) three disks attached.
>
> $ ~> lsusb
> Bus 002 Device 002: ID 152d:0567 JMicron Technology Corp. / JMicron USA 
> Technology Corp. JMS567 SATA 6Gb/s bridge
> Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
> …
>
> $ ~> ls -l /dev/disk/by-id/
> total 0
> …
> lrwxrwxrwx 1 root root  9 May 18 00:20 
> usb-JMicron_Generic_DISK00_0123456789ABCDEF-0:0 -> ../../sdc
> lrwxrwxrwx 1 root root 10 May 18 00:20 
> usb-JMicron_Generic_DISK00_0123456789ABCDEF-0:0-part1 -> ../../sdc1
> lrwxrwxrwx 1 root root 10 May 18 00:20 
> usb-JMicron_Generic_DISK00_0123456789ABCDEF-0:0-part9 -> ../../sdc9
> lrwxrwxrwx 1 root root  9 May 18 00:20 
> usb-JMicron_Generic_DISK01_0123456789ABCDEF-0:1 -> ../../sdd
> lrwxrwxrwx 1 root root 10 May 18 00:20 
> usb-JMicron_Generic_DISK01_0123456789ABCDEF-0:1-part1 -> ../../sdd1
> lrwxrwxrwx 1 root root  9 May 18 00:20 
> usb-JMicron_Generic_DISK02_0123456789ABCDEF-0:2 -> ../../sde
> lrwxrwxrwx 1 root root 10 May 18 00:20 
> usb-JMicron_Generic_DISK02_0123456789ABCDEF-0:2-part1 -> ../../sde1
> lrwxrwxrwx 1 root root 10 May 18 00:20 
> usb-JMicron_Generic_DISK02_0123456789ABCDEF-0:2-part9 -> ../../sde9
> …
>
> I am running a ZFS filesystem on those… (actually two pools…). The system 
> seems to run fine as long as there is only reading going on or only writing 
> to one disk (possibly from somewhere else)….
>
> However once I start a copy operation (here data coming from one of the above 
> devices and going to the two others (in a mirror configuration), I get 
> frequent io errors from the kernel:
>
> May 17 22:53:13 gserv kernel: [  474.505548] xhci_hcd :00:14.0: ERROR 
> Transfer event for disabled endpoint or incorrect stream ring
> May 17 22:53:13 gserv kernel: [  474.505670] xhci_hcd :00:14.0: 
> @00026e54c460   0400 02088001
> May 17 22:53:43 gserv kernel: [  504.804185] sd 2:0:0:0: [sda] tag#5 
> uas_eh_abort_handler 0 uas-tag 6 inflight: CMD IN
> May 17 22:53:43 gserv kernel: [  504.804192] sd 2:0:0:0: [sda] tag#5 CDB: 
> Read(16) 88 00 00 00 00 00 74 e9 b3 48 00 00 01 00 00 00
> May 17 22:53:43 gserv kernel: [  504.804252] sd 2:0:0:0: [sda] tag#3 
> uas_eh_abort_handler 0 uas-tag 4 inflight: CMD IN
> May 17 22:53:43 gserv kernel: [  504.804256] sd 2:0:0:0: [sda] tag#3 CDB: 
> Read(16) 88 00 00 00 00 00 74 e9 b2 48 00 00 01 00 00 00
> May 17 22:53:43 gserv kernel: [  504.804299] sd 2:0:0:0: [sda] tag#1 
> uas_eh_abort_handler 0 uas-tag 2 inflight: CMD IN
> May 17 22:53:43 gserv kernel: [  504.804303] sd 2:0:0:0: [sda] tag#1 CDB: 
> Read(16) 88 00 00 00 00 00 74 e9 b1 48 00 00 01 00 00 00
> May 17 22:53:43 gserv kernel: [  504.804383] sd 2:0:0:2: [sdc] tag#7 
> uas_eh_abort_handler 0 uas-tag 1 inflight: CMD OUT
> May 17 22:53:43 gserv kernel: [  504.804387] sd 2:0:0:2: [sdc] tag#7 CDB: 
> Write(16) 8a 00 00 00 00 00 e8 23 79 10 00 00 01 00 00 00
> May 17 22:53:43 gserv kernel: [  504.804419] sd 2:0:0:2: [sdc] tag#6 
> uas_eh_abort_handler 0 uas-tag 7 inflight: CMD OUT
> May 17 22:53:43 gserv kernel: [  504.804422] sd 2:0:0:2: [sdc] tag#6 CDB: 
> Write(16) 8a 00 00 00 00 00 e8 23 78 10 00 00 01 00 00 00
> May 17 22:53:43 gserv kernel: [  504.804468] sd 2:0:0:2: [sdc] tag#0 
> uas_eh_abort_handler 0 uas-tag 3 inflight: CMD OUT
> May 17 22:53:43 gserv kernel: [  504.804472] sd 2:0:0:2: [sdc] tag#0 CDB: 
> Write(16) 8a 00 00 00 00 00 e8 23 77 10 00 00 01 00 00 00
> May 17 22:53:43 gserv kernel: [  504.804510] sd 2:0:0:2: [sdc] tag#2 
> uas_eh_abort_handler 0 uas-tag 5 inflight: CMD OUT
> May 17 22:53:43 gserv kernel: [  504.804514] sd 2:0:0:2: [sdc] tag#2 CDB: 
> Write(16) 8a 00 00 00 00 00 e8 23 76 10 00 00 01 00 00 00
> May 17 22:53:43 gserv kernel: [  504.804542] sd 2:0:0:2: [sdc] tag#4 
> uas_eh_abort_handler 0 uas-tag 8 inflight: CMD OUT
> May 17 22:53:43 gserv kernel: [  504.804545] sd 2:0:0:2: [sdc] tag#4 CDB: 
> Write(16) 8a 00 00 00 00 00

Re: uas failing on multiple disk access on a jmicron JMS567 bridge

2017-05-24 Thread Christoph Gohle

> 
>> On 22 May 2017, at 14:37, Mathias Nyman  
>> wrote:
>> 
>> On 22.05.2017 11:48, Christoph Gohle wrote:
>>> Hey Mathias,
>>> 
>>> 
 On 19 May 2017, at 09:58, Mathias Nyman  
 wrote:
 
> 
 
 4.11 kernel has xhci traces enabled, could you try to reproduce it with 
 4.11?
 xhci traces can be enabled with:
 
 echo 1 > /sys/kernel/debug/tracing/events/xhci-hcd/enable
 
 If you know how to reliably reproduce this then please enable tracing just 
 before
 triggering this. It generates a lot of data.
 
 -Mathias
>>> I would be able to do xhci traces with a 4.10 kernel (4.10.0-21-generic 
>>> #23~16.04.1-Ubuntu SMP). Don’t really want to go to 4.11. . Still 
>>> interested?
>> 
>> xhci got more useful tracing support in 4.11,
>> Sure, you can try if there's something in 4.10
OK. Now I managed (had to update-initramfs, stupid…)

So I triggered the failiure with xhci-hcd tracing enabled. I can’t make much 
sense out of the trace. Maybe you can? The trace is as follows (I removed 
repeating ‘Removing canceled TD...':


# tracer: nop
#
# entries-in-buffer/entries-written: 1536/1536   #P:4
#
#  _-=> irqs-off
# / _=> need-resched
#| / _---=> hardirq/softirq
#|| / _--=> preempt-depth
#||| / delay
#   TASK-PID   CPU#  TIMESTAMP  FUNCTION
#  | |   |      | |
 device 1 sectio-3419  [002] d...   326.179876: xhci_dbg_cancel_urb: Cancel URB 
8dcc6f68f800, dev 5.2, ep 0x84, starting at offset 0x209e5c320
  -0 [002] d.h.   326.179952: xhci_cmd_completion:
trb_dma=@26e01a820, trb_va=@8dcc6e01a820, status=0100, flags=04008400
  -0 [002] d.h.   326.179959: xhci_dbg_cancel_urb: Removing 
canceled TD starting at 0x209e5c320 (dma).
.
.
.
  -0 [002] d.h.   326.180141: xhci_dbg_cancel_urb: Removing 
canceled TD starting at 0x209e5c710 (dma).
 device 1 sectio-3419  [002] d...   326.180198: xhci_dbg_cancel_urb: Cancel URB 
8dcc6f68c000, dev 5.2, ep 0x84, starting at offset 0x209e5c720
  -0 [002] d.h.   326.180243: xhci_cmd_completion:
trb_dma=@26e01a830, trb_va=@8dcc6e01a830, status=0100, flags=04008400
  -0 [002] d.h.   326.180248: xhci_dbg_cancel_urb: Removing 
canceled TD starting at 0x209e5c720 (dma).
.
.
.
  -0 [002] d.h.   326.180420: xhci_dbg_cancel_urb: Removing 
canceled TD starting at 0x209e5cb10 (dma).
 device 1 sectio-3419  [002] d...   326.180465: xhci_dbg_cancel_urb: Cancel URB 
8dcc6f68c800, dev 5.2, ep 0x84, starting at offset 0x1ebb11730
  -0 [002] d.h.   326.180504: xhci_cmd_completion:
trb_dma=@26e01a840, trb_va=@8dcc6e01a840, status=0100, flags=04008400
  -0 [002] d.h.   326.180507: xhci_dbg_cancel_urb: Removing 
canceled TD starting at 0x1ebb11730 (dma).
  -0 [002] d.h.   326.180511: xhci_dbg_cancel_urb: Finding 
endpoint context
  -0 [002] d.h.   326.180515: xhci_dbg_cancel_urb: Cycle 
state = 0x1
  -0 [002] d.h.   326.180517: xhci_dbg_cancel_urb: New 
dequeue segment = 8dcc040c7b40 (virtual)
  -0 [002] d.h.   326.180523: xhci_dbg_cancel_urb: New 
dequeue pointer = 0x1ebb11740 (DMA)
  -0 [002] d.h.   326.180528: xhci_dbg_cancel_urb: Removing 
canceled TD starting at 0x1ebb11740 (dma).
.
.
.
  -0 [002] d.h.   326.180697: xhci_dbg_cancel_urb: Removing 
canceled TD starting at 0x1ebb11b00 (dma).
  -0 [002] d.h.   326.180700: xhci_dbg_cancel_urb: Set TR Deq 
Ptr cmd, new deq seg = 8dcc040c7b40 (0x1ebb11000 dma), new deq ptr = 
8dcbebb11740 (0x1ebb11740 dma), new cycle = 1
  -0 [002] dNh.   326.180738: xhci_cmd_completion:
trb_dma=@26e01a850, trb_va=@8dcc6e01a850, status=0100, flags=04008400
  -0 [002] dNh.   326.180741: xhci_dbg_cancel_urb: Successful 
Set TR Deq Ptr cmd, deq = @1ebb11740
 device 1 sectio-3419  [002] d...   326.180847: xhci_dbg_cancel_urb: Cancel URB 
8dcc6f689800, dev 5.2, ep 0x84, starting at offset 0x1ebb11b10
  -0 [003] d.H.   326.180918: xhci_cmd_completion:
trb_dma=@26e01a860, trb_va=@8dcc6e01a860, status=0100, flags=04008400
  -0 [003] d.H.   326.180924: xhci_dbg_cancel_urb: Removing 
canceled TD starting at 0x1ebb11b10 (dma).
  -0 [003] d.H.   326.180931: xhci_dbg_cancel_urb: Finding 
endpoint context
  -0 [003] d.H.   326.180936: xhci_dbg_cancel_urb: Cycle 
state = 0x1
  -0 [003] d.H.   326.180941: xhci_dbg_cancel_urb: New 
dequeue segment = 8dcc040c7b40 (virtual)
  -0 [003] d.H.   326.180945: xhci_dbg_cancel_urb: New 
dequeue pointer = 0x1ebb11b20 (DMA)
  -0 [003] d.H.   326.180948: xhci_dbg_cancel_urb: Removing

Re: uas failing on multiple disk access on a jmicron JMS567 bridge

2017-05-24 Thread Christoph Gohle

OK. now I am stuck as uas remains blacklisted even after removing the entry in 
modprobe.d. Why? syslog says:

May 24 09:17:49 gserv kernel: [2.288977] usb 2-2: UAS is blacklisted for 
this device, using usb-storage instead

Like this I can’t test.

Cheers,
Christoph

> On 22 May 2017, at 14:37, Mathias Nyman  wrote:
> 
> On 22.05.2017 11:48, Christoph Gohle wrote:
>> Hey Mathias,
>> 
>> 
>>> On 19 May 2017, at 09:58, Mathias Nyman  
>>> wrote:
>>> 
 
>>> 
>>> 4.11 kernel has xhci traces enabled, could you try to reproduce it with 
>>> 4.11?
>>> xhci traces can be enabled with:
>>> 
>>> echo 1 > /sys/kernel/debug/tracing/events/xhci-hcd/enable
>>> 
>>> If you know how to reliably reproduce this then please enable tracing just 
>>> before
>>> triggering this. It generates a lot of data.
>>> 
>>> -Mathias
>> I would be able to do xhci traces with a 4.10 kernel (4.10.0-21-generic 
>> #23~16.04.1-Ubuntu SMP). Don’t really want to go to 4.11. . Still interested?
> 
> xhci got more useful tracing support in 4.11,
> Sure, you can try if there's something in 4.10
> 
>> 
>> Where do these traces go?
>> 
> 
> mount -t debugfs none /sys/kernel/debug
> cat /sys/kernel/debug/tracing/trace
> 
> -Mathias

--
Christoph Gohle
christ...@gohle.org








signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: uas failing on multiple disk access on a jmicron JMS567 bridge

2017-05-22 Thread Mathias Nyman


On 22.05.2017 11:48, Christoph Gohle wrote:

Hey Mathias,



On 19 May 2017, at 09:58, Mathias Nyman  wrote:





4.11 kernel has xhci traces enabled, could you try to reproduce it with 4.11?
xhci traces can be enabled with:

echo 1 > /sys/kernel/debug/tracing/events/xhci-hcd/enable

If you know how to reliably reproduce this then please enable tracing just 
before
triggering this. It generates a lot of data.

-Mathias

I would be able to do xhci traces with a 4.10 kernel (4.10.0-21-generic 
#23~16.04.1-Ubuntu SMP). Don’t really want to go to 4.11. . Still interested?


xhci got more useful tracing support in 4.11,
Sure, you can try if there's something in 4.10



Where do these traces go?



mount -t debugfs none /sys/kernel/debug
cat /sys/kernel/debug/tracing/trace

-Mathias
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: uas failing on multiple disk access on a jmicron JMS567 bridge

2017-05-22 Thread Christoph Gohle

Hey Mathias,


> On 19 May 2017, at 09:58, Mathias Nyman  wrote:
> 
>> 
> 
> 4.11 kernel has xhci traces enabled, could you try to reproduce it with 4.11?
> xhci traces can be enabled with:
> 
> echo 1 > /sys/kernel/debug/tracing/events/xhci-hcd/enable
> 
> If you know how to reliably reproduce this then please enable tracing just 
> before
> triggering this. It generates a lot of data.
> 
> -Mathias
I would be able to do xhci traces with a 4.10 kernel (4.10.0-21-generic 
#23~16.04.1-Ubuntu SMP). Don’t really want to go to 4.11. . Still interested?

Where do these traces go?

Cheers,
Christoph








signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: uas failing on multiple disk access on a jmicron JMS567 bridge

2017-05-19 Thread Mathias Nyman


On 18.05.2017 17:30, Christoph Gohle wrote:

Hi,

I have seen several reports around the internet regarding failing io on 
USB-SATA bridges. However, these reports seem to be partially old and/or fixes 
proposed are implemented in my kernel but don’t fix things. Therefore I thought 
I report here again. If this is know/duplicate please apologise.

I am running on ubuntu 16.04 LTS with kernel

$ ~> uname -a
Linux gserv 4.8.0-52-generic #55~16.04.1-Ubuntu SMP Fri Apr 28 14:36:29 UTC 
2017 x86_64 x86_64 x86_64 GNU/Linux

I was also using the 4.4.0-75-generic version of the kernel before, with same 
results. I am having a JMS567 bridge with (currently) three disks attached.

$ ~> lsusb
Bus 002 Device 002: ID 152d:0567 JMicron Technology Corp. / JMicron USA 
Technology Corp. JMS567 SATA 6Gb/s bridge
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
…

$ ~> ls -l /dev/disk/by-id/
total 0
…
lrwxrwxrwx 1 root root  9 May 18 00:20 
usb-JMicron_Generic_DISK00_0123456789ABCDEF-0:0 -> ../../sdc
lrwxrwxrwx 1 root root 10 May 18 00:20 
usb-JMicron_Generic_DISK00_0123456789ABCDEF-0:0-part1 -> ../../sdc1
lrwxrwxrwx 1 root root 10 May 18 00:20 
usb-JMicron_Generic_DISK00_0123456789ABCDEF-0:0-part9 -> ../../sdc9
lrwxrwxrwx 1 root root  9 May 18 00:20 
usb-JMicron_Generic_DISK01_0123456789ABCDEF-0:1 -> ../../sdd
lrwxrwxrwx 1 root root 10 May 18 00:20 
usb-JMicron_Generic_DISK01_0123456789ABCDEF-0:1-part1 -> ../../sdd1
lrwxrwxrwx 1 root root  9 May 18 00:20 
usb-JMicron_Generic_DISK02_0123456789ABCDEF-0:2 -> ../../sde
lrwxrwxrwx 1 root root 10 May 18 00:20 
usb-JMicron_Generic_DISK02_0123456789ABCDEF-0:2-part1 -> ../../sde1
lrwxrwxrwx 1 root root 10 May 18 00:20 
usb-JMicron_Generic_DISK02_0123456789ABCDEF-0:2-part9 -> ../../sde9
…

I am running a ZFS filesystem on those… (actually two pools…). The system seems 
to run fine as long as there is only reading going on or only writing to one 
disk (possibly from somewhere else)….

However once I start a copy operation (here data coming from one of the above 
devices and going to the two others (in a mirror configuration), I get frequent 
io errors from the kernel:

May 17 22:53:13 gserv kernel: [  474.505548] xhci_hcd :00:14.0: ERROR 
Transfer event for disabled endpoint or incorrect stream ring
May 17 22:53:13 gserv kernel: [  474.505670] xhci_hcd :00:14.0: 
@00026e54c460   0400 02088001


4.11 kernel has xhci traces enabled, could you try to reproduce it with 4.11?
xhci traces can be enabled with:

echo 1 > /sys/kernel/debug/tracing/events/xhci-hcd/enable

If you know how to reliably reproduce this then please enable tracing just 
before
triggering this. It generates a lot of data.

-Mathias
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: uas failing on multiple disk access on a jmicron JMS567 bridge

2017-05-18 Thread Greg KH

On Thu, May 18, 2017 at 04:30:02PM +0200, Christoph Gohle wrote:
> Hi,
> 
> I have seen several reports around the internet regarding failing io
> on USB-SATA bridges. However, these reports seem to be partially old
> and/or fixes proposed are implemented in my kernel but don’t fix
> things. Therefore I thought I report here again. If this is
> know/duplicate please apologise.
> 
> I am running on ubuntu 16.04 LTS with kernel
> 
> $ ~> uname -a
> Linux gserv 4.8.0-52-generic #55~16.04.1-Ubuntu SMP Fri Apr 28 14:36:29 UTC 
> 2017 x86_64 x86_64 x86_64 GNU/Linux

Note, this is a very old kernel release, from last October, lots and
lots of USB fixes have happened since then.  Any chance you can try 4.11
and see if you are having the same issue?  We can't do anything about
old kernels like this, but your distro can, so you can ask them about
this if you want.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

uas failing on multiple disk access on a jmicron JMS567 bridge

2017-05-18 Thread Christoph Gohle

Hi,

I have seen several reports around the internet regarding failing io on 
USB-SATA bridges. However, these reports seem to be partially old and/or fixes 
proposed are implemented in my kernel but don’t fix things. Therefore I thought 
I report here again. If this is know/duplicate please apologise.

I am running on ubuntu 16.04 LTS with kernel

$ ~> uname -a
Linux gserv 4.8.0-52-generic #55~16.04.1-Ubuntu SMP Fri Apr 28 14:36:29 UTC 
2017 x86_64 x86_64 x86_64 GNU/Linux

I was also using the 4.4.0-75-generic version of the kernel before, with same 
results. I am having a JMS567 bridge with (currently) three disks attached.

$ ~> lsusb
Bus 002 Device 002: ID 152d:0567 JMicron Technology Corp. / JMicron USA 
Technology Corp. JMS567 SATA 6Gb/s bridge
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
…

$ ~> ls -l /dev/disk/by-id/
total 0
…
lrwxrwxrwx 1 root root  9 May 18 00:20 
usb-JMicron_Generic_DISK00_0123456789ABCDEF-0:0 -> ../../sdc
lrwxrwxrwx 1 root root 10 May 18 00:20 
usb-JMicron_Generic_DISK00_0123456789ABCDEF-0:0-part1 -> ../../sdc1
lrwxrwxrwx 1 root root 10 May 18 00:20 
usb-JMicron_Generic_DISK00_0123456789ABCDEF-0:0-part9 -> ../../sdc9
lrwxrwxrwx 1 root root  9 May 18 00:20 
usb-JMicron_Generic_DISK01_0123456789ABCDEF-0:1 -> ../../sdd
lrwxrwxrwx 1 root root 10 May 18 00:20 
usb-JMicron_Generic_DISK01_0123456789ABCDEF-0:1-part1 -> ../../sdd1
lrwxrwxrwx 1 root root  9 May 18 00:20 
usb-JMicron_Generic_DISK02_0123456789ABCDEF-0:2 -> ../../sde
lrwxrwxrwx 1 root root 10 May 18 00:20 
usb-JMicron_Generic_DISK02_0123456789ABCDEF-0:2-part1 -> ../../sde1
lrwxrwxrwx 1 root root 10 May 18 00:20 
usb-JMicron_Generic_DISK02_0123456789ABCDEF-0:2-part9 -> ../../sde9
…

I am running a ZFS filesystem on those… (actually two pools…). The system seems 
to run fine as long as there is only reading going on or only writing to one 
disk (possibly from somewhere else)….

However once I start a copy operation (here data coming from one of the above 
devices and going to the two others (in a mirror configuration), I get frequent 
io errors from the kernel:

May 17 22:53:13 gserv kernel: [  474.505548] xhci_hcd :00:14.0: ERROR 
Transfer event for disabled endpoint or incorrect stream ring
May 17 22:53:13 gserv kernel: [  474.505670] xhci_hcd :00:14.0: 
@00026e54c460   0400 02088001
May 17 22:53:43 gserv kernel: [  504.804185] sd 2:0:0:0: [sda] tag#5 
uas_eh_abort_handler 0 uas-tag 6 inflight: CMD IN
May 17 22:53:43 gserv kernel: [  504.804192] sd 2:0:0:0: [sda] tag#5 CDB: 
Read(16) 88 00 00 00 00 00 74 e9 b3 48 00 00 01 00 00 00
May 17 22:53:43 gserv kernel: [  504.804252] sd 2:0:0:0: [sda] tag#3 
uas_eh_abort_handler 0 uas-tag 4 inflight: CMD IN
May 17 22:53:43 gserv kernel: [  504.804256] sd 2:0:0:0: [sda] tag#3 CDB: 
Read(16) 88 00 00 00 00 00 74 e9 b2 48 00 00 01 00 00 00
May 17 22:53:43 gserv kernel: [  504.804299] sd 2:0:0:0: [sda] tag#1 
uas_eh_abort_handler 0 uas-tag 2 inflight: CMD IN
May 17 22:53:43 gserv kernel: [  504.804303] sd 2:0:0:0: [sda] tag#1 CDB: 
Read(16) 88 00 00 00 00 00 74 e9 b1 48 00 00 01 00 00 00
May 17 22:53:43 gserv kernel: [  504.804383] sd 2:0:0:2: [sdc] tag#7 
uas_eh_abort_handler 0 uas-tag 1 inflight: CMD OUT
May 17 22:53:43 gserv kernel: [  504.804387] sd 2:0:0:2: [sdc] tag#7 CDB: 
Write(16) 8a 00 00 00 00 00 e8 23 79 10 00 00 01 00 00 00
May 17 22:53:43 gserv kernel: [  504.804419] sd 2:0:0:2: [sdc] tag#6 
uas_eh_abort_handler 0 uas-tag 7 inflight: CMD OUT
May 17 22:53:43 gserv kernel: [  504.804422] sd 2:0:0:2: [sdc] tag#6 CDB: 
Write(16) 8a 00 00 00 00 00 e8 23 78 10 00 00 01 00 00 00
May 17 22:53:43 gserv kernel: [  504.804468] sd 2:0:0:2: [sdc] tag#0 
uas_eh_abort_handler 0 uas-tag 3 inflight: CMD OUT
May 17 22:53:43 gserv kernel: [  504.804472] sd 2:0:0:2: [sdc] tag#0 CDB: 
Write(16) 8a 00 00 00 00 00 e8 23 77 10 00 00 01 00 00 00
May 17 22:53:43 gserv kernel: [  504.804510] sd 2:0:0:2: [sdc] tag#2 
uas_eh_abort_handler 0 uas-tag 5 inflight: CMD OUT
May 17 22:53:43 gserv kernel: [  504.804514] sd 2:0:0:2: [sdc] tag#2 CDB: 
Write(16) 8a 00 00 00 00 00 e8 23 76 10 00 00 01 00 00 00
May 17 22:53:43 gserv kernel: [  504.804542] sd 2:0:0:2: [sdc] tag#4 
uas_eh_abort_handler 0 uas-tag 8 inflight: CMD OUT
May 17 22:53:43 gserv kernel: [  504.804545] sd 2:0:0:2: [sdc] tag#4 CDB: 
Write(16) 8a 00 00 00 00 00 e8 23 75 10 00 00 01 00 00 00
May 17 22:53:43 gserv kernel: [  504.804600] scsi host2: 
uas_eh_bus_reset_handler start
May 17 22:53:44 gserv kernel: [  504.924432] usb 2-2: reset SuperSpeed USB 
device number 2 using xhci_hcd
May 17 22:53:44 gserv kernel: [  504.946883] scsi host2: 
uas_eh_bus_reset_handler success

These keep repeating unitl the filesystem driver (or the user) stops the 
transfer.

I first was suspecting a hardware bug, but after playing around I found that 
thing seem to be OK once I use usb-storage instead of uas. If I add the 
following line to the modprobe blacklist

$ ~> cat /etc/modprobe.d/blacklist_uas.conf

Re: uas failing on multiple disk access on a jmicron JMS567 bridge

Re: uas failing on multiple disk access on a jmicron JMS567 bridge

Re: uas failing on multiple disk access on a jmicron JMS567 bridge

Re: uas failing on multiple disk access on a jmicron JMS567 bridge

uas failing on multiple disk access on a jmicron JMS567 bridge

Re: uas failing on multiple disk access on a jmicron JMS567 bridge

Re: uas failing on multiple disk access on a jmicron JMS567 bridge

Re: uas failing on multiple disk access on a jmicron JMS567 bridge

Re: uas failing on multiple disk access on a jmicron JMS567 bridge

Re: uas failing on multiple disk access on a jmicron JMS567 bridge

Re: uas failing on multiple disk access on a jmicron JMS567 bridge

Re: uas failing on multiple disk access on a jmicron JMS567 bridge

Re: uas failing on multiple disk access on a jmicron JMS567 bridge

uas failing on multiple disk access on a jmicron JMS567 bridge

14 matches

Site Navigation

Mail list logo

Footer information