USB 3.0 OTG not switching to superspeed
Comments
-
Thanks for the heads-up!dcleri wrote:Please be aware that there are some Errata shared by Intel which involves USB (both 2.0 and 3.0) issues.
Best regards,
David -
The list is public and available at this address: http://www.intel.com/content/www/us/en/processors/atom/atom-z8000-spec-update.html
-
dcleri wrote:The list is public and available at this address: http://www.intel.com/content/www/us/en/processors/atom/atom-z8000-spec-update.html
Any timeline for a fix? USB3 - one of the selling points - is admittedly unusable as of now... -
-
I tried several configurations to get USB 3.0 OTG working (in host mode).
Hardware
Up Board Firmware: UPC1BM0R
USB Hub: EXSYS EX-1183HMVS - Genesys Logic Chipset (https://www.amazon.de/gp/product/B00L4BY3GG/ref=oh_aui_detailpage_o08_s01?ie=UTF8&psc=1)
USB External Enclosure: Salcar USB 3.0 2,5" - JMicron Chipset (https://www.amazon.de/gp/product/B01D9KX7K2/ref=oh_aui_detailpage_o04_s00?ie=UTF8&psc=1)
Software
Kernel: Linux Helium 4.7.2-1-ARCH #1 SMP PREEMPT Sat Aug 20 23:02:56 CEST 2016 x86_64 GNU/Linux
0. General Notes
The disk is formatted with btrfs.
Basic functionality tests were done as follows:
[ol]
[li]"lsusb -t": check that the disk device has been found and is reported as USB3 superspeed device ("..., 5000M")[/li]
[li]Copy some data to the disk: "dd if=/dev/zero of=/media/helium-daten/testfile bs=1M count=5000 conv=fdatasync,notrunc status=progress"[/li]
[li]btrfs scrub start -B /media/helium-daten (let it run for about 10 minutes, then abort)[/li]
[li]invoke custom backup procedure: this includes creating a snapshot, capturing file checksums and copying the data to a different machine via rsync over ssh. Due to the design of my custom backup script, there's some time without disk IO between the end of checksum calculation and actual copying of data[/li]
[li]check dmesg output for: 1) I/O errors 2) usb device resets " reset SuperSpeed USB device number ? using xhci_hcd" 3) UAS (usb attached scsi) errors like " tag#0 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD IN" - the test is passed if there were no I/O errors. Few device resets are tolerable, frequent device resets (like every 30s) are intolarable)[/li]
[/ol]
The tests were repeated with all possbile USB OTG mode bios settings (Auto, ACPI, PCI, Disabled). The default setting was PCI. I could not identify noticable difference between these options during the tests. At the end I sticked to ACPI for no proper reason.
1. Find a working OTG cable
The first task was to find a working OTG cable, which happened to be rather complicated.
"Working" below means that the disk device has been detected (lsusb test). It does not mean that I/O tests passed.
Working: LINDY 31612 - USB 3.0 OTG Kabel mit Aufladefunktion (power plug left floating - not psu attached) (https://www.amazon.de/gp/product/B00SN1BOW6/ref=oh_aui_search_detailpage?ie=UTF8&psc=1)
Working (note: this cable is USB2 480M High Speed only)Pure² High Speed Micro USB Host OTG Kabel 90° (https://www.amazon.de/gp/product/B009VD25KK/ref=oh_aui_search_detailpage?ie=UTF8&psc=1)
Not Working: InLine 35300Q Buchse A auf Stecker Micro B gewinkelt USB 3.0 Adapter (https://www.amazon.de/gp/product/B00BWLAF3S/ref=oh_aui_detailpage_o07_s01?ie=UTF8&psc=1)
Not Working: deleyCON [0,2m] USB 3.0 Super Speed OTG Adapter (https://www.amazon.de/dp/B00WHZASVM/ref=twister_B00WHZAKDS?_encoding=UTF8&psc=1)
Not yet tested: Smart-Planet hochwertiges USB OTG (On-the-go) Adapter USB 3.0 Micro Stecker auf USB A Buchse (https://www.amazon.de/gp/product/B00V28DTKW/ref=oh_aui_detailpage_o00_s00?ie=UTF8&psc=1)
Not yet tested: Wicked Chili USB-A Adapter Kabel für microUSB 3.0 OTG Handy & Tablet (https://www.amazon.de/gp/product/B00MMDN0BO/ref=oh_aui_detailpage_o01_s00?ie=UTF8&psc=1)
2. Perform basic I/O-Tests with the LINDY 31612 adapter
Without any usb-storage / usbcore kernel module tweaks (see below) there have been frequent (~ every 30s) usb device resets, UAS errors and btrfs I/O errors.
The UAS errors are consequently gone when disabling UAS: "modprobe usb-storage quirks=<device-id>:u" or "options usb-storage quirks=<device-id>:u" in modprobe.conf. Nevertheless frequent device resets have been observed. I/O errors occured during the backup test:Sep 10 00:58:45 Helium kernel: scsi 0:0:0:0: rejecting I/O to offline device Sep 10 00:58:45 Helium kernel: scsi 0:0:0:0: [sda] killing request Sep 10 00:58:45 Helium kernel: scsi 0:0:0:0: [sda] UNKNOWN(0x2003) Result: hostbyte=0x01 driverbyte=0x00 Sep 10 00:58:45 Helium kernel: scsi 0:0:0:0: [sda] CDB: opcode=0x28 28 00 00 0e 89 20 00 00 20 00 Sep 10 00:58:45 Helium kernel: blk_update_request: I/O error, dev sda, sector 952608
I was able to solve this kind of I/O error by disabling usb autosuspend by adding "options usbcore autosuspend=-1" to modprobe.conf.
What remains are device resets. Sometimes less, sometimes more. Most of the time with a period of approx 30s.[So Sep 11 16:43:07 2016] sd 2:0:0:0: [sda] tag#0 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD IN [So Sep 11 16:43:07 2016] sd 2:0:0:0: [sda] tag#0 CDB: opcode=0x28 28 00 00 16 03 80 00 01 c0 00 [So Sep 11 16:43:07 2016] scsi host2: uas_eh_bus_reset_handler start [So Sep 11 16:43:07 2016] usb 2-1.1: reset SuperSpeed USB device number 3 using xhci_hcd [So Sep 11 16:43:07 2016] scsi host2: uas_eh_bus_reset_handler success
-
Hi episource,
Thanks for your excellent and detailed report on your USB3.0 storage testing!
We have also tested the board with other USB3.0 devices like Gigbit Eth to USB3.0 and the RealSense Camera from the RDK kit. The results are very good and so the stability of those devices with the UP Board via OTG cable.
We noticed some instability only when using storage devices, in particular external disks more than USB sticks.
Of course it is critical to choose a good USB3.0 OTG cable as many of them are quite poor in quality and the USB3.0 OTG interface suffers in stability from it.
Powering the disk from an external source doesn't change the results.
Disabling UAS from the kernel instead improved things considerably. As you may notice our ubilinux kernel (and soon the Ubuntu 4.4 one) comes with UAS disabled by default.
We decided to remove it as the driver cause instability on many other Cherry Trail and Braswell boards out there (you can find out after a quick google search). Unfortunately more recent kernels don't solve the uas issues (tested up to 4.8-rc5).
In the coming weeks we are going to verify if new BIOS fixes provided by Intel could improve/fix the USB3.0 stability with storage devices (and UAS). -
In my use case I tested my upboards with USB 3 camera's from PixeLINK and where the camera's function fine on my laptop, I see periodic disconnects/reconnects when connecting them to my upboard. So the statement where storage only is affected is simply not true.
Those camera's are not connected to the upboard (and functioning fine) however at USB 2.0 speeds. (we fortunately do not need the high framerate for our usecase). -
Hi ElieDeBrauwer,
Thanks for reporting your use case and testing too, your results are very important!
Our statement is that from our testing with :
- Gigabit Eth to USB3.0
- RealSense camera
we don't see stability issues there, while we do in our storage testing.
Are the PixeLINK cameras working fine over USB3.0 while connected to other hosts (e.g. laptop with ubuntu 16.04, 4.4 kernel)? -
Hi dcleri,
No problems seen with the PixeLINK camera's (my laptop + Debian works fine on usb 2.0 and usb 3.0 (we even tested this on windows ;-) ), upboard and usb 2.0 works fine). The only problematic situation is upboard + usb 3.0. Only difference between my laptop on usb 3.0 and up-board on usb 3.0 is that my laptop obviously doesn't have an OTG connector but a regular USB connector so I had to use a different set. -
Thanks ElieDeBrauwer,
What Kernel version is running on your laptop and which CPU? -
Hi Dcleri,
That has imho nothing to do at all with this issue. My laptop is simply following Debian Testing (currently 4.5.something and has a stock i5-3320M), and the camera manufacturer (which focuses on high end industrial applications) has likely designed/tested their camera on numerous other combinations. -
episource wrote:I tried several configurations to get USB 3.0 OTG working (in host mode).
(...)
I have to correct myself. I did some more tests and the I/O erros are back. This time not due to "rejecting I/O to offline device", but:Sep 12 15:50:00 Helium kernel: sd 0:0:0:0: timing out command, waited 180s Sep 12 15:50:00 Helium kernel: sd 0:0:0:0: [sda] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08 Sep 12 15:50:00 Helium kernel: sd 0:0:0:0: [sda] tag#0 Sense Key : 0x2 [current] Sep 12 15:50:00 Helium kernel: sd 0:0:0:0: [sda] tag#0 ASC=0x4 ASCQ=0x1 Sep 12 15:50:00 Helium kernel: sd 0:0:0:0: [sda] tag#0 CDB: opcode=0x28 28 00 00 01 5d 60 00 00 08 00 Sep 12 15:50:00 Helium kernel: blk_update_request: I/O error, dev sda, sector 89440
I'll try to attach the disk directly to the board without hub. Lets see.
Btw: Can anyone explain what's the difference between the four OTG modes in the Bios (Disabled, PCI, ACPI, Auto)? While looking for a working OTG cable I tried them all and did not notice any difference... -
Please let us know as soon as drives are stable.
I need an external USB3 SSD as I intend to use my 4GB/64GB up board with an external SSD as a small dual boot Windows / Linux development box at USB3 transfer rates, as USB2 is too slow for my purposes.
USB3 gig-e, cameras etc do not interest me, fast attached storage does.
Btw, this is another excellent reason why the next model should have SATA.dcleri wrote:Hi episource,
Thanks for your excellent and detailed report on your USB3.0 storage testing!
We have also tested the board with other USB3.0 devices like Gigbit Eth to USB3.0 and the RealSense Camera from the RDK kit. The results are very good and so the stability of those devices with the UP Board via OTG cable.
We noticed some instability only when using storage devices, in particular external disks more than USB sticks.
Of course it is critical to choose a good USB3.0 OTG cable as many of them are quite poor in quality and the USB3.0 OTG interface suffers in stability from it.
Powering the disk from an external source doesn't change the results.
Disabling UAS from the kernel instead improved things considerably. As you may notice our ubilinux kernel (and soon the Ubuntu 4.4 one) comes with UAS disabled by default.
We decided to remove it as the driver cause instability on many other Cherry Trail and Braswell boards out there (you can find out after a quick google search). Unfortunately more recent kernels don't solve the uas issues (tested up to 4.8-rc5).
In the coming weeks we are going to verify if new BIOS fixes provided by Intel could improve/fix the USB3.0 stability with storage devices (and UAS). -
episource wrote:1. Find a working OTG cable
The first task was to find a working OTG cable, which happened to be rather complicated.
"Working" below means that the disk device has been detected (lsusb test). It does not mean that I/O tests passed.
I finished testing all cables:
Working: LINDY 31612 - USB 3.0 OTG Kabel mit Aufladefunktion (power plug left floating - not psu attached) (https://www.amazon.de/gp/product/B00SN1BOW6/ref=oh_aui_search_detailpage?ie=UTF8&psc=1)
Working: Wicked Chili USB-A Adapter Kabel für microUSB 3.0 OTG Handy & Tablet (https://www.amazon.de/gp/product/B00MMDN0BO/ref=oh_aui_detailpage_o01_s00?ie=UTF8&psc=1)
Working (note: this cable is USB2 480M High Speed only)Pure² High Speed Micro USB Host OTG Kabel 90° (https://www.amazon.de/gp/product/B009VD25KK/ref=oh_aui_search_detailpage?ie=UTF8&psc=1)
Working (note: this cable is USB2 480M High Speed only): Smart-Planet hochwertiges USB OTG (On-the-go) Adapter USB 3.0 Micro Stecker auf USB A Buchse (https://www.amazon.de/gp/product/B00V28DTKW/ref=oh_aui_detailpage_o00_s00?ie=UTF8&psc=1)
Not Working: InLine 35300Q Buchse A auf Stecker Micro B gewinkelt USB 3.0 Adapter (https://www.amazon.de/gp/product/B00BWLAF3S/ref=oh_aui_detailpage_o07_s01?ie=UTF8&psc=1)
Not Working: deleyCON [0,2m] USB 3.0 Super Speed OTG Adapter (https://www.amazon.de/dp/B00WHZASVM/ref=twister_B00WHZAKDS?_encoding=UTF8&psc=1)
Sadly I still can't use external storage: When attached to the UP-Board there are lots of device resets and several I/O-Errors! -
I am unable to run
Intel Realsense.
Everything is installed correctly.
Instuction followed exactly
The terminal said something similar to
no plugged realsense.
It's been two weeks that I work to make it work without result.
No USB3 Port detected
I noticed lots of distortion during startup.
The Ubutu logo starts flashing with horizontal lines.
Works great on my laptop ASUS.
Under Window 10.
Thank, Jean-Sebastien -
It is really amazing that an advertised feature is admittedly not working (even in the products they sell as we speak) and UP is not actively working to fix it.
Months ago they promised a BIOS update to address the issue but they just let the discussion die down!
Anyone out there that feels cheated as i do..? -
For me most issues were solved by using another power supply: At first I used a Hensych 3A power supply (https://www.amazon.de/gp/product/B00E0NHKEM/). This caused random issues even with a single USB3 stick!
Now I'm successfully using a MEANWELL SGA40E05-P1J 5A power supply together with the following USB3 parts:
[ul]
[li]Transcend JetFlash 700 series 64GB + 128GB (https://www.amazon.de/gp/product/B00T78GG4K/)[/li]
[li]AmazonBasics USB 3.0 4port hub (https://www.amazon.de/gp/product/B00E0NHKEM/)[/li]
[li]Wicked Chili USB-A Adapter Kabel für microUSB 3.0 OTG Handy & Tablet ( www.amazon.de/gp/product/B00MMDN0BO/)[/li]
[/ul]
The Salcar USB 3.0 enclosure (https://www.amazon.de/gp/product/B01D9KX7K2/) I have been using temporarily showed errors on a linux desktop computer, too. So I did not retest it after switching the power supply. -
interesting, but still, i bought the official PSU and we were promised an update for the bios. i really hope it will be released soon (before up squared comes out?!)
-
episource wrote:For me most issues were solved by using another power supply: At first I used a Hensych 3A power supply (https://www.amazon.de/gp/product/B00E0NHKEM/). This caused random issues even with a single USB3 stick!
Now I'm successfully using a MEANWELL SGA40E05-P1J 5A power supply together with the following USB3 parts:
[ul]
[li]Transcend JetFlash 700 series 64GB + 128GB (https://www.amazon.de/gp/product/B00T78GG4K/)[/li]
[li]AmazonBasics USB 3.0 4port hub (https://www.amazon.de/gp/product/B00E0NHKEM/)[/li]
[li]Wicked Chili USB-A Adapter Kabel für microUSB 3.0 OTG Handy & Tablet ( www.amazon.de/gp/product/B00MMDN0BO/)[/li]
[/ul]
The Salcar USB 3.0 enclosure (https://www.amazon.de/gp/product/B01D9KX7K2/) I have been using temporarily showed errors on a linux desktop computer, too. So I did not retest it after switching the power supply.
Anyway, it is not a power supply issue for sure. In addition to the original one, I tried with professional lab equipment and no changes. It is a (recognised) hardware bug -
MarcFinns wrote:It is really amazing that an advertised feature is admittedly not working (even in the products they sell as we speak) and UP is not actively working to fix it.
Months ago they promised a BIOS update to address the issue but they just let the discussion die down!
Anyone out there that feels cheated as i do..?
I totally agree. After trying half a dozen cables, couple of USB3 HDD-docs, 3 Superspeed USB hubs I have yet to see a single superspeed device.
I feel betrayed as focus has clearly shifted to the new board version and next round of income.
The people who supported the initial project have been ignored.
With the limited IO-capabilities these SBCs have, USB3 is the thing that would raise UP above raspberries and such. -
full ack!
-
MarcFinns wrote:If you use a USB3 flash stick I bet it is not going at super speed. Did you check..?
Anyway, it is not a power supply issue for sure. In addition to the original one, I tried with professional lab equipment and no changes. It is a (recognised) hardware bug
lsusb claims that the device would be working at superspeed:$ lsusb -t /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 5000M |__ Port 1: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 5000M |__ Port 2: Dev 4, If 0, Class=Mass Storage, Driver=usb-storage, 5000M |__ Port 3: Dev 5, If 0, Class=Mass Storage, Driver=usb-storage, 5000M |__ Port 4: Dev 6, If 0, Class=Mass Storage, Driver=usb-storage, 5000M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/7p, 480M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M |__ Port 2: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 480M |__ Port 7: Dev 4, If 0, Class=Hub, Driver=hub/4p, 480M |__ Port 4: Dev 5, If 0, Class=Vendor Specific Class, Driver=, 480M
I did not do any speed tests, but I have no reason to doubt lsusb's output.
As written previously, I have configured the usbcore module to disable usb autosuspend. This improved the situation while I was using the old 3A power supply. Didn't retest the default settings with the new 5A power supply, though.$ cat /etc/modprobe.d/modprobe.conf # ... options usbcore autosuspend=-1
-
episource wrote:MarcFinns wrote:If you use a USB3 flash stick I bet it is not going at super speed. Did you check..?
Anyway, it is not a power supply issue for sure. In addition to the original one, I tried with professional lab equipment and no changes. It is a (recognised) hardware bug
lsusb claims that the device would be working at superspeed:$ lsusb -t /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 5000M |__ Port 1: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 5000M |__ Port 2: Dev 4, If 0, Class=Mass Storage, Driver=usb-storage, 5000M |__ Port 3: Dev 5, If 0, Class=Mass Storage, Driver=usb-storage, 5000M |__ Port 4: Dev 6, If 0, Class=Mass Storage, Driver=usb-storage, 5000M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/7p, 480M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M |__ Port 2: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 480M |__ Port 7: Dev 4, If 0, Class=Hub, Driver=hub/4p, 480M |__ Port 4: Dev 5, If 0, Class=Vendor Specific Class, Driver=, 480M
I did not do any speed tests, but I have no reason to doubt lsusb's output.
As written previously, I have configured the usbcore module to disable usb autosuspend. This improved the situation while I was using the old 3A power supply. Didn't retest the default settings with the new 5A power supply, though.$ cat /etc/modprobe.d/modprobe.conf # ... options usbcore autosuspend=-1
-
MarcFinns wrote:Will give it a try. But did you run an extensive disk throughout test? My ssd/hdd also work at super speed but after a while they throw errors
I had frequent IO errors while using the old 3A power supply.
Note: The option can also be changed at runtime. See the kernel docs for details: https://www.kernel.org/doc/Documentation/usb/power-management.txt -
I also managed to get a usb stick working/negotiated at Superspeed, but if I remember correctly, other USB 3.0 devices would fail, and even the USB stick behaved unstable after actually trying to use it. Have you examined the dmesg output during use ? Or even better, have you tried putting a live image on it and using it as a boot medium ?
-
ElieDeBrauwer wrote:I also managed to get a usb stick working/negotiated at Superspeed, but if I remember correctly, other USB 3.0 devices would fail, and even the USB stick behaved unstable after actually trying to use it. Have you examined the dmesg output during use ? Or even better, have you tried putting a live image on it and using it as a boot medium ?
I'm not using the usb sticks as boot medium. Previously there have been frequent I/O errors (see below for a kernel log snippet) when copying data from and to the USB3 devices. I got rid of all these errors by using another power supply.episource wrote:episource wrote:I tried several configurations to get USB 3.0 OTG working (in host mode).
(...)
I have to correct myself. I did some more tests and the I/O erros are back. This time not due to "rejecting I/O to offline device", but:Sep 12 15:50:00 Helium kernel: sd 0:0:0:0: timing out command, waited 180s Sep 12 15:50:00 Helium kernel: sd 0:0:0:0: [sda] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08 Sep 12 15:50:00 Helium kernel: sd 0:0:0:0: [sda] tag#0 Sense Key : 0x2 [current] Sep 12 15:50:00 Helium kernel: sd 0:0:0:0: [sda] tag#0 ASC=0x4 ASCQ=0x1 Sep 12 15:50:00 Helium kernel: sd 0:0:0:0: [sda] tag#0 CDB: opcode=0x28 28 00 00 01 5d 60 00 00 08 00 Sep 12 15:50:00 Helium kernel: blk_update_request: I/O error, dev sda, sector 89440
I'll try to attach the disk directly to the board without hub. Lets see.
Btw: Can anyone explain what's the difference between the four OTG modes in the Bios (Disabled, PCI, ACPI, Auto)? While looking for a working OTG cable I tried them all and did not notice any difference... -
My cell phone is USB 3.0 port. I use ESEEKGO usb type c cable to charge fast. You can try it.
-
Any updates on this issue ?
The board is kinda useless for me without USB3 working properly.
I'm running the last available BIOS (UPC1BM0X) with kernel 4.8.
Somebody mentioned disabling UAS to improve things. Is this something that can be configured with kernel cmd line or do I have to rebuild the kernel ?
The device I work with is never detected as superspeed, but works fine at 480M link speed. -
Dear dcleri,
I have tried lots of ways to make the USB3 OTG port up, but not succeeded . I have tried on windows 10, Ubilinux (4.4.0-ubi4-amd64) and ubuntu also but i have not succeeded to connect USB3 devise on up-board.
Also tried with three diffrent adaptors and cables, still no success.
Also tried with two diffrent up-boards, still no success.
do you have any update on this , or any dignostic method to chek whether i had done any mistek or any hardware problem.
Thanks And Regards
Nilesh Mane -
The wider community has been waiting on this issue for a year, and the question goes always unanswered. I guess by now we have to assume that it is a hardware bug that the team does not acknowledge as it would impair one of the selling points. I a little while the UP^2 will be out and we will be left in the cold. Move on.