I think that JMS567 is mostly broken nowadays in Linux UAS
Mine in an Orico multibay encolsure produce a lot of CMD timeout
Recently Orico is just silently disabling in firmware the UAS support
for this bridge (still advertising it on the webpage, usual chinese
behaviour)
Try to disable UAS with us
Mine was just a question from a non expert in kernel internals
Bye
2018-03-22 18:29 GMT+01:00 Alan Stern :
> On Thu, 22 Mar 2018, Menion wrote:
>
>> You are right.
>> But what if usb-storage check if the deferred uas bind does not succeed?
>
> That is not possible, for
Would be technically possible that the function uas_use_uas_driver
checks if the uas driver is loaded (not just configured) before
telling the usb-storage to leave the device to the uas module?
Bye
2018-03-22 16:16 GMT+01:00 Alan Stern :
> On Wed, 21 Mar 2018, Menion wrote:
>
>> Wel
50, Mike Lothian wrote:
>>> Also here's the kernel config for the router, it's now 4.9.87
>>>
>>>
>>>
>>> On 21 March 2018 at 17:23, Menion wrote:
>>>> Yes that was the point.
>>>> Curious that the device worked fine in 17.01.4 an
t;
> I'd like to point the device worked fine when running a 4.4 kernel on
> LEDE 17.01.4
>
> On 21 March 2018 at 17:10, Menion wrote:
>> Then it is so strange, it is completely dead from USB host perspective
>> in UASP mode
>> What lsusb shows when it is attached
gt;
> It's a USB3 caddy that has its own power supply, that you can put any
> SATA hard disk into, I currently have a 1.5TB drive in it.
>
> On 21 March 2018 at 17:00, Menion wrote:
>> I see a disconnect from port 4:1 of some un-enumerated device then
>> connect
;
> On 21 March 2018 at 16:45, Menion wrote:
>> You sent the dmesg with quirks :u enabled
>> We need the one without quirks :u, when the device takes UAS driver
>> Bye
>>
>> 2018-03-21 17:41 GMT+01:00 Mike Lothian :
>>> Hi
>>>
>>> Pleas
You sent the dmesg with quirks :u enabled
We need the one without quirks :u, when the device takes UAS driver
Bye
2018-03-21 17:41 GMT+01:00 Mike Lothian :
> Hi
>
> Please find attached my dmesg
>
> Cheers
>
> Mike
>
> On 21 March 2018 at 16:12, Oliver Neukum wrote:
>> Am Mittwoch, den 21.03.2018
READ_CAPACITY_16 does not have anything to do in blacklisting via
quirks the device to usb-storage
I have checked it in 4.9.86 and it is not quirked to usb-storage:
/* Reported by Oliver Neukum */
UNUSUAL_DEV( 0x174c, 0x55aa, 0x0100, 0x0100,
"ASMedia",
"AS2105",
USB_SC_DEVICE, USB_PR_DEVICE, NUL
Can you please attach dmesg output?
2018-03-21 16:39 GMT+01:00 Mike Lothian :
> Hi
>
> I'm running kernel 4.9.86 on my router
>
> I have to:
>
> echo 174c:55aa:u > /sys/module/usb_storage/parameters/quirks
>
> To get it to work correctly
>
> I'm attaching the output of lsusb -v
>
> I'm guessing it
So in summary Orico is lying about this particular enclosure
2018-03-16 16:20 GMT+01:00 Alan Stern :
> On Fri, 16 Mar 2018, Menion wrote:
>
>> Hi Alan&Greg
>> Yes, sorry, I thought it was simpler. I confirm that also the 4
>> endpoints required for UAS operation a
ifferent
To recap: the capabilities are shown by the device itself, it is not
possible that the USB host itself takes the decision to "filter" out
some capabilities, right?
2018-03-16 15:53 GMT+01:00 Alan Stern :
> On Fri, 16 Mar 2018, Menion wrote:
>
>> Hi Greg
>> Yes Oric
that show
up as UASP capable
2018-03-16 15:04 GMT+01:00 Greg KH :
> On Fri, Mar 16, 2018 at 02:10:43PM +0100, Menion wrote:
>> Hi all
>> I have in my hands a multi bay SATA enclosure, with some unidentified
>> SATA multiport but using the JMicron JMS567 USB to SATA bridge.
>&
Hi all
I have in my hands a multi bay SATA enclosure, with some unidentified
SATA multiport but using the JMicron JMS567 USB to SATA bridge.
This bridge is known to support UASP but in this particular
implementation, due to something weird/buggy (most probably the
firmware) doesn't who up as UASP c
Alan Stern :
> On Fri, 9 Mar 2018, Menion wrote:
>
>> Hi all
>> I am discussing about an issue I get with my Orico USBtoSATA 5 bays enclosure
>> The issue is that every 5 minutes the BTRFS perform a revalidate
>> action that will fill the dmesg with this log:
>>
Hi all
I am discussing about an issue I get with my Orico USBtoSATA 5 bays enclosure
The issue is that every 5 minutes the BTRFS perform a revalidate
action that will fill the dmesg with this log:
[ 98.917660] sd 0:0:0:1: [sdb] Very big device. Trying to use READ
CAPACITY(16).
[ 99.057592] sd
pid
0567: 500
and here the usb info
menion@Menionubuntu:~$ lsusb
Bus 002 Device 005: ID 152d:0567 JMicron Technology Corp. / JMicron
USA Technology Corp. JMS567 SATA 6Gb/s bridge
Bus 002 Device 004: ID 1058:107c Western Digital Technologies, Inc.
Elements Desktop (WDBWLG)
Bus 002 Device 003
start
[ 2696.691299] usb 2-1.4: reset SuperSpeed USB device number 4 using xhci_hcd
[ 2696.714701] scsi host2: uas_eh_device_reset_handler success
2018-02-14 9:29 GMT+01:00 Menion :
> Upgraded to 4.15.3 and now UAS works, strange...
> Anyhow now the enclosure is connected via an USB 3.0 HUB
nel driver in use: xhci_hcd
2018-02-14 8:36 GMT+01:00 Menion :
> That is very strange
> My device has same vid:pid of your one, but it goes blacklisted...
> I am running kernel 4.15.1, I will try to upgrade
> What kind of enclosure is yours? Mine is an Orico 9553RU3 5 bay
> enclosu
12:57 AM, Menion wrote:
>
>>
>> I wanted to test my enclosure with an hub, but I have just realized
>> that now the JMS567 is UAS blacklisted by default in kernel
>> 4.15.x.
>> Can you check if it still works removing the dedicated hub external
>> p
2018-02-10 1:00 GMT+01:00 Chris Murphy :
> On Fri, Feb 9, 2018 at 3:57 AM, Menion wrote:
>> There are multiple reports of UAS issue together with JMS567 (from myself
>> also)
>> Question: you mentioned that connecting the enclosure to an
>> intermediate USB HUB
There are multiple reports of UAS issue together with JMS567 (from myself also)
Question: you mentioned that connecting the enclosure to an
intermediate USB HUB is a workaround.
Can you specify if your PC USB port is USB 3.0 and if the HUB is USB
3.0 as well, and if it is self-powered or not?
2018
gt;
> On Wed, Feb 7, 2018 at 8:09 PM, Menion wrote:
>> This is not fully true
>> Multibay enclosure may have problem, see my thread "uas failing on
>> multiple disk access on a jmicron JMS567 bridge"
>>
>> 2018-02-07 15:38 GMT+01:00 Tushar Nimkar :
>>
This is not fully true
Multibay enclosure may have problem, see my thread "uas failing on
multiple disk access on a jmicron JMS567 bridge"
2018-02-07 15:38 GMT+01:00 Tushar Nimkar :
> Thanks Adrian and Greg.
>
> On Wed, Feb 7, 2018 at 7:59 PM, Greg KH wrote:
>> On Wed, Feb 07, 2018 at 12:13:36PM
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
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
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 brid
27 matches
Mail list logo
