search

1000001101000 / Debian_on_Buffalo

Tools for Installing/Running Debian on Buffalo ARM based Linkstation/Terastation/Kurobox/Cloudstor devices.
333 stars 42 forks source link

USB issue with LS-QL #92

Open masterlog80 opened 3 years ago

masterlog80 commented 3 years ago

Hello! I have successfully installed Debian on my Linkstation LS-QL and everything work properly except for the USB ports. In details, the front USB port seems disabled, not even powering connected devices. The port on the back seems functioning but some devices (e.g. XFS USB HDD which was working with the stock firmware and can be read by other linux distros) connected there are unavailable (e.g. fdisk -l not showing), despite the USB module seems being fine:

root@debian:/# lsusb
Bus 002 Device 019: ID 059f:102a LaCie, Ltd Rikiki Hard Drive
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
root@debian:/#

Some suspicious messages on dmesg:

[ 1931.596175] usb 2-1: new high-speed USB device number 19 using orion-ehci
[ 1931.984401] usb 2-1: New USB device found, idVendor=059f, idProduct=102a, bcdDevice= 1.00
[ 1931.992692] usb 2-1: New USB device strings: Mfr=10, Product=11, SerialNumber=5
[ 1932.000098] usb 2-1: Product: LaCie Device
[ 1932.004270] usb 2-1: SerialNumber: D0********FF
[ 1932.031515] usb-storage 2-1:1.0: USB Mass Storage device detected
[ 1932.062292] scsi host1: usb-storage 2-1:1.0
[ 1933.244142] usb 2-1: reset high-speed USB device number 19 using orion-ehci
[ 1933.768167] usb 2-1: reset high-speed USB device number 19 using orion-ehci
[ 1934.088148] usb 2-1: reset high-speed USB device number 19 using orion-ehci
[ 1934.640130] usb 2-1: device not accepting address 19, error -32
[ 1934.772144] usb 2-1: reset high-speed USB device number 19 using orion-ehci
[ 1935.104154] usb 2-1: reset high-speed USB device number 19 using orion-ehci

Otherwise a simple USB stick can be read:

[ 2785.387483] usb 2-1: new full-speed USB device number 37 using orion-ehci
[ 2785.951523] usb 2-1: new high-speed USB device number 38 using orion-ehci
[ 2786.114617] usb 2-1: New USB device found, idVendor=14cd, idProduct=125c, bcdDevice= 3.00
....
[ 2788.243512] usb 2-1: reset high-speed USB device number 38 using orion-ehci
[ 2788.451006] sd 1:0:0:0: [sde] Attached SCSI removable disk

Any idea?

Regards,

1000001101000 commented 3 years ago

I did USB testing when I made the device tree for this device but don’t remember the details. Since I have mine online now it should be easy to do some tests.

how did you get your device back online? Can you post some details about your /boot, md0 etc?

1000001101000 commented 3 years ago

I confirmed my front usb doesn't work either, I haven't noticed an issue with the back one so far but have only tried mounting a small usb key.

This SoC is unusual in a few ways. I previously discovered that the GPIO binding for orion-pinctl only supports up to pin 19 even though the "auto" switch is connected to pin 22. I tried checking if the power pin for the front port was one of these higher pins but I only seem to be able to assign them as inputs. I took a look at the stock kernel source and couldn't tell if they are on separate pins or not, it appears they share the same one but the source is pretty confusing to me.

I also took a quick look at the kernel output from the stock kernel vs Debian's. The addresses for the USB controllers are different which is not unusual but the stock controllers are 0x200 apart where debian has them 0x50000 apart which seems wrong. for most other devices I've looked at those address either match stock or at least have matching offsets.

Stock:

Marvell USB EHCI Host controller #0: c055b600
Marvell USB EHCI Host controller #1: c055b400
ehci_marvell ehci_marvell.4523: new USB bus registered, assigned bus number 1
ehci_marvell ehci_marvell.4523: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
ehci_marvell ehci_marvell.167817: new USB bus registered, assigned bus number 2
ehci_marvell ehci_marvell.167817: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004

Debian

[   29.508374] orion-ehci f1050000.ehci: new USB bus registered, assigned bus number 1
[   29.660679] orion-ehci f1050000.ehci: USB 2.0 started, EHCI 1.00
[   30.172722] orion-ehci f10a0000.ehci: new USB bus registered, assigned bus number 2
[   30.335334] orion-ehci f10a0000.ehci: USB 2.0 started, EHCI 1.00

I'm going to look at the code for some other orion5x devices and see if this has been noticed/dealt with before.

1000001101000 commented 3 years ago

I played around with the address and believe I've confirmed that is already correct. The dmesg output if very different if you try to initialize the device with the wrong addess.

masterlog80 commented 3 years ago

how did you get your device back online? Can you post some details about your /boot, md0 etc?

I just made a fresh install, so I don't think there is nothing special on my device. However I have ordered a new HDD case to see if with a different newer hardware it may work, so I will test that in a couple of days. Thank you for your effort on this! 👍

Regards,

1000001101000 commented 3 years ago

if you get a moment, run mdadm --detail /dev/md0 and make sure all the components show as active. I assume this was part of the issue earlier.

masterlog80 commented 3 years ago

Here it is:

root@NAS:~# mdadm --detail /dev/md0
/dev/md0:
           Version : 0.90
     Creation Time : Thu Nov  1 00:23:40 2007
        Raid Level : raid1
        Array Size : 1003904 (980.38 MiB 1028.00 MB)
     Used Dev Size : 1003904 (980.38 MiB 1028.00 MB)
      Raid Devices : 4
     Total Devices : 4
   Preferred Minor : 0
       Persistence : Superblock is persistent

       Update Time : Sun Mar  7 22:14:06 2021
             State : clean
    Active Devices : 4
   Working Devices : 4
    Failed Devices : 0
     Spare Devices : 0

Consistency Policy : resync

              UUID : a371418d:b5df9251:c94c2ba3:57c86304
            Events : 0.18

    Number   Major   Minor   RaidDevice State
       0       8        1        0      active sync   /dev/sda1
       1       8       17        1      active sync   /dev/sdb1
       2       8       33        2      active sync   /dev/sdc1
       3       8       49        3      active sync   /dev/sdd1
root@NAS:~#

Regards,

1000001101000 commented 3 years ago

Looking at some other devices it looks like there are some that actually do list PINs 22-24 for some USB related purposes. I'm attempting to patch a kernel to enable output on these pins so that I can test them.

1000001101000 commented 3 years ago

I was able to enable my front USB port by patching the kernel to enable GPIOs 19-31 and then manually setting GPIO19 high.

I'm still thinking about how to best make this change available. For most other changes I can just update the device tree but the device tree would then be incompatible with the Debian kernel (or any kernel without my kernel patch).

masterlog80 commented 3 years ago

I see. I am waiting for the new HDD case for the other issue with the back USB, so I will keep an eye to this thread.

Thanks!

masterlog80 commented 3 years ago

I used a new USB 3.0 HDD case but I still can't see the device using fdisk -l, and I see (different) errors on log:

root@NAS:~# lsusb                                      
Bus 002 Device 048: ID 13fd:5900 Initio Corporation    
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
root@NAS:~# dmesg
.... 
[170331.217724] usb 2-1: new high-speed USB device number 48 using orion-ehci
[170331.417381] usb 2-1: New USB device found, idVendor=13fd, idProduct=5900, bcdDevice= 9.10
[170331.425729] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[170331.433062] usb 2-1: Product: External           
[170331.436966] usb 2-1: Manufacturer: Generic
[170331.441299] usb 2-1: SerialNumber: 6*****32         
[170331.474538] scsi host1: uas                        
[170331.506821] usb 2-1: stat urb: status -71          
[170352.201595] scsi 1:0:0:0: tag#12 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD
[170352.209099] scsi 1:0:0:0: tag#12 CDB: Inquiry 12 00 00 00 24 00
[170352.218364] scsi host1: uas_eh_device_reset_handler start
[170352.357600] usb 2-1: reset high-speed USB device number 48 using orion-ehci
[170352.547865] scsi host1: uas_eh_device_reset_handler success
[170352.560191] usb 2-1: stat urb: status -71          
[170352.565477] scsi 1:0:0:0: tag#12 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD
[170352.572981] scsi 1:0:0:0: tag#12 CDB: Test Unit Ready 00 00 00 00 00 00
[170352.579831] scsi host1: uas_eh_device_reset_handler start
[170352.733606] usb 2-1: reset high-speed USB device number 48 using orion-ehci
[170352.924741] scsi host1: uas_eh_device_reset_handler success
[170352.930510] scsi 1:0:0:0: Device offlined - not ready after error recovery
root@NAS:~#

I hope this can help!

Regards,

1000001101000 commented 3 years ago

searching around a bit I can see that others have run into this issue with various combinations of enclosures and devices that use the ehci-orion driver (including at least one on the Buffalo forum in their stock firmware). I didn't find an authoritative answer but saw a few ideas.

This seems to have helped for one person: https://bbs.archlinux.org/viewtopic.php?pid=1081842#p1081842

Someone else had partial success increasing this value: /sys/module/scsi_mod/parameters/inq_timeout

A bunch of others seemed to improve by putting the enclosure behind a powered USB hub.

At some point I'll take a look an see if there have been improvements in this driver recently, we can try out a newer kernel at some point and see if that helps.

When I get front-side USB support sorted out we can also see if it works any better on that port. I'm working on getting the needed changes into the custom kernel that I offer for the Terastation II/III. I may end up re-working how that build process works as part of that effort.

masterlog80 commented 3 years ago

Hello, and thank you for getting back. I had already tried some of those solutions but no one worked for me. However It doesn't seem the root causes is related to enclosure model/type as also USB devices which seems working (e.g. shown into fdisk -l, etc.) are not usable as R/W operations end with an error and devices are getting disconnected:

root@NAS:~# lsusb
Bus 002 Device 032: ID 8564:1000 Transcend Information, Inc. JetFlash
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
root@NAS:~# fdisk /dev/sde

Welcome to fdisk (util-linux 2.33.1).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.
.... 
Command (m for help): n
Partition type
p   primary (0 primary, 0 extended, 4 free)
e   extended (container for logical partitions)
Select (default p): p
Partition number (1-4, default 1):
First sector (2048-30277631, default 4096):
Last sector, +/-sectors or +/-size{K,M,G,T,P} (4096-30277631, default 30277631):

Created a new partition 1 of type 'Linux' and of size 14.4 GiB.

Command (m for help): w
fdisk: failed to write disklabel: Input/output error
root@NAS:~# lsusb
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
root@NAS:~#

So, at least at my side (and I have tried more than 10 devices) there is no way of using an USB HDD or key. And the issue seems to be related to a similar power output trouble I faced in the past.

Regards,

1000001101000 commented 3 years ago

I'm nearly finished with the re-work of the kernel build process. Once I generate the new kernels and complete some tests I'll post some info on how to switch the my kernel repo. At some point in that process I'll also create a special device tree that includes the entries for the front-usb and power button. I'm still not sure how I want to maintain that long term.

When I'm near the device again I can try some R/W operations with a usb disk on mine and see if I see any problems like yours.

masterlog80 commented 3 years ago

Hello, thank you very much for your effort on this! I didn't notice any issues with power button but I will keep this monitored!

Regards,

1000001101000 commented 3 years ago

The power button is connected to one of these unsupported GPIO pins like the front-side USB power. Using the mainline kernel I can’t add the button to the device tree which would make it more difficult ise thst button to trigger evens in Debian. It won’t affect powering the device or anything like that.

masterlog80 commented 3 years ago

I was definitely able to set up a script for shutting down the device one pressed for late than 5sec. using triggerhappy to run scripts, (same for the function button), however I am looking forward to hearing from you.

Regards,

1000001101000 commented 3 years ago

Sorry, it’s the switch on the back not the power button which is affected.

masterlog80 commented 3 years ago

Ah yeah, that's not working. But I am not sure about its purpose 😅

Regards,

masterlog80 commented 3 years ago

Hello @1000001101000 I am wondering if you have some time to look into this. As I can't use the USB port I can't take any backups for some times, os if there is something I can help you with this please lemme to know!

Thanks for your effort!

1000001101000 commented 3 years ago

I recently got a "new" laptop which needed some work to get working properly under Debian, this used up much of my time for a little while. I've posted most of my notes if you're interested: https://github.com/1000001101000/HP_Chromebook_15

I've automated the kernel build process I spoke of earlier which should let me move forward now. I should have instructions for installing my kernel and a new device tree for you to test in the next few days.

masterlog80 commented 3 years ago

Thank you very much @1000001101000 , I will keep an eye on this and on the URL you shared!

Regards,

1000001101000 commented 3 years ago

The first step is to uninstall the default debian kernel and install my custom kernel from the repository:

apt-get -y remove $(dpkg -l | grep linux-image | gawk '{print $2}')
apt-get install -y apt-transport-https gnupg
wget -qO - https://raw.githubusercontent.com/1000001101000/Debian_on_Buffalo/master/PPA/KEY.gpg | apt-key add -
echo "deb https://raw.githubusercontent.com/1000001101000/Debian_on_Buffalo/master/PPA/ buster main" > /etc/apt/sources.list.d/tsxl_kernel.list
apt-get update
apt-get install -y linux-image-tswxl

Next make sure there were no errors reported and verify you still have /boot/uImage.buffalo and /boot/initrd.buffalo

Then reboot and verify that the new kernel was used:

Linux lsql-Buster 4.19.181 #9 Sat Apr 10 22:08:11 UTC 2021 armv5tel GNU/Linux

Once you're on the custom kernel you can install the dtb that activates the front usb port.

I've attached it as a zip. unpack it and put it into /etc/flash-kernel/dtbs, then run flash-kernel to install it. Then reboot again.

Let me know if you have any questions.

lsql-dtb.zip

masterlog80 commented 3 years ago

Thank you very much @1000001101000 , I run those commands by a script and it ended (without any specific errors apart the confirmation of removing the kernel in use, which I approved) as below:

<....>
Reading state information... Done
The following packages will be REMOVED:
  linux-image-4.19.0-14-marvell linux-image-marvell
0 upgraded, 0 newly installed, 2 to remove and 29 not upgraded.
<....>
The following additional packages will be installed:
  linux-image-4.19.181
The following NEW packages will be installed:
  linux-image-4.19.181 linux-image-tswxl
0 upgraded, 2 newly installed, 0 to remove and 29 not upgraded.
<....>
Installing /etc/flash-kernel/dtbs/orion5x-linkstation-lsql.dtb into /boot/dtbs/4.19.181/./orion5x-linkstation-lsql.dtb
Taking backup of orion5x-linkstation-lsql.dtb.
Installing new orion5x-linkstation-lsql.dtb.
Kernel /boot/vmlinuz-4.19.181 does not match any of the expected flavors (marvell orion5x), therefore not writing it to flash.
root@NAS:~#

Content of /boot is shown below:

root@NAS:~# ls /boot/ -l
total 18528
-rw-r--r-- 1 root root 1648004 Apr 11 07:08 System.map-4.19.181
-rw-r--r-- 1 root root  169763 Apr 11 07:08 config-4.19.181
lrwxrwxrwx 1 root root      44 Apr 19 09:23 dtb -> dtbs/4.19.181/./orion5x-linkstation-lsql.dtb
lrwxrwxrwx 1 root root      44 Apr 19 09:23 dtb-4.19.181 -> dtbs/4.19.181/./orion5x-linkstation-lsql.dtb
drwxr-xr-x 4 root root    4096 Apr 19 09:22 dtbs
-rw-r--r-- 1 root root 6480756 Mar  7 09:38 initrd.buffalo
-rw-r--r-- 1 root root 6481328 Apr 19 09:22 initrd.img-4.19.181
drwx------ 2 root root   16384 Mar  7 07:16 lost+found
-rw-r--r-- 1 root root 2063746 Mar  7 09:38 uImage.buffalo
-rwxr-xr-x 1 root root 2054448 Apr 11 07:08 vmlinuz-4.19.181
root@NAS:~#

I rebooted the NAS and it doesn't seem to come back successfully, power lamp is blinking for about 1h and device doesn't reply to PING, SSH, etc. So I proceeded to reinstall the OS.

I hope this can be useful for you. Regards,

masterlog80 commented 3 years ago

After some tries, I have completed to reinstall the OS using the latest installer files. Once done, I have login to the system and checked the kernel:

user@debian:/$ uname -a
Linux debian 4.19.0-16-marvell #1 Debian 4.19.181-1 (2021-03-19) armv5tel GNU/Linux
user@debian:/$

So, the installer is still using the kernel without the usb patch?

Regards,

1000001101000 commented 3 years ago

I haven't made my kernel the default for this device yet, I'm still not sure if I plan to do that automatically or not.

before you install the kernel again modify /usr/share/flash-kernel/db/buffalo_devices.db and remove the following line from the LSQL entry (the last one in the file): Kernel-Flavors: marvell orion5x

That should prevent the error that you ran into.

When I started this project I didn't intend to maintain a kernel image like this (or even a full installer) since I wanted to minimize the number of things that depend on me. As the project has grown I've added devices that can only work with a custom kernel which caused me to change direction somewhat. I'm still not entirely sure what my philosophy is for the future.

masterlog80 commented 3 years ago

Hello, Thank you and I definitely understand the trouble on maintaining a different kernels and installers for multiple devices. I just finished reinstalling the OS, I will try to modify that file, rebooting and checking the kernel later.

For now, thank you!

masterlog80 commented 3 years ago

Hello, here are my steps (I attached the source file renamed as .txt) on a fresh newly installed Buffalo LS^QL:

root@debian:~# cat /usr/share/flash-kernel/db/buffalo_devices.db | grep Kernel-Flavors
<....>
Kernel-Flavors: marvell kirkwood
Kernel-Flavors: marvell kirkwood
Kernel-Flavors: marvell orion5x
root@debian:~# 
root@debian:~# vi /usr/share/flash-kernel/db/buffalo_devices.db | grep Kernel-Flavors
<Changes made>
root@debian:~# cat /usr/share/flash-kernel/db/buffalo_devices.db | grep Kernel-Flavors
<....>
Kernel-Flavors: armmp armmp-lpae
Kernel-Flavors: marvell kirkwood
Kernel-Flavors: marvell kirkwood
root@debian:~#

Then I run your instructions as a script and got some warning as expected: Schermata 2021-04-20 alle 12 05 15 I saved the output on script.txt file.

root@debian:~# dpkg --list | grep linux-image
rc  linux-image-4.19.0-16-marvell 4.19.181-1                   armel        Linux 4.19 for Marvell Kirkwood/Orion
ii  linux-image-4.19.181          4.19.181-9                   armel        Linux kernel, version 4.19.181
ii  linux-image-tswxl             4.19-9                       armel        linux-image metapackage for buffalo armel devices without PCI
root@debian:~# ls -al /boot
total 26900
drwxr-xr-x  4 root root    4096 Apr 20 12:14 .
drwxr-xr-x 18 root root    4096 Apr 20 12:05 ..
-rw-r--r--  1 root root  169763 Apr 11 07:08 config-4.19.181
lrwxrwxrwx  1 root root      44 Apr 20 12:13 dtb -> dtbs/4.19.181/./orion5x-linkstation-lsql.dtb
lrwxrwxrwx  1 root root      44 Apr 20 12:13 dtb-4.19.181 -> dtbs/4.19.181/./orion5x-linkstation-lsql.dtb
drwxr-xr-x  4 root root    4096 Apr 20 12:13 dtbs
-rw-r--r--  1 root root 6481446 Apr 20 12:14 initrd.buffalo
-rw-r--r--  1 root root 6481100 Apr 20 11:37 initrd.buffalo.bak
-rw-r--r--  1 root root 6481382 Apr 20 12:13 initrd.img-4.19.181
drwx------  2 root root   16384 Apr 20 09:42 lost+found
-rw-r--r--  1 root root 1648004 Apr 11 07:08 System.map-4.19.181
-rw-r--r--  1 root root 2062426 Apr 20 12:14 uImage.buffalo
-rw-r--r--  1 root root 2062986 Apr 20 11:37 uImage.buffalo.bak
-rwxr-xr-x  1 root root 2054448 Apr 11 07:08 vmlinuz-4.19.181
root@debian:~# reboot
root@debian:~# Connection to 192.168.10.118 closed by remote host.
Connection to 192.168.10.118 closed.

However, after reboot doesn't seem to use the new kernel:

root@debian:~$ uname -a
Linux debian 4.19.181 #9 Sat Apr 10 22:08:11 UTC 2021 armv5tel GNU/Linux
root@debian:~$

Regards,

buffalo_devices.db.txt script.txt

1000001101000 commented 3 years ago

That looks like the correct kernel, 4.19.181 instead of 4.19.0-16 (both are based on the same source).

masterlog80 commented 3 years ago

Oh, thank you for your clarification. I will try running the "lsql-dtb.zip" file.

Regards,

masterlog80 commented 3 years ago

Hello, @1000001101000 , I have just completed the steps and currently using target kernel:

root@debian:~# uname -a
Linux debian 4.19.181 #9 Sat Apr 10 22:08:11 UTC 2021 armv5tel GNU/Linux
root@debian:~#

As result, the USB port on the front is perfectly working and I can attach my USB HDD which is recognized:

Bus 002 Device 039: ID 13fd:5900 Initio Corporation 
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
root@debian:~#

I confirmed it can be mounted and R/W data there.

However, the USB port on the back is still not working, as generate some errors as below once a device is connected

root@debian:/mnt# dmesg
<....>
[  652.321460] usb 2-1: new high-speed USB device number 53 using orion-ehci
[  652.519767] usb 2-1: unable to read config index 0 descriptor/start: -71
[  652.526554] usb 2-1: can't read configurations, error -71
[  652.661466] usb 2-1: new high-speed USB device number 54 using orion-ehci
[  652.842791] usb 2-1: unable to get BOS descriptor or descriptor too short
[  652.872894] usb 2-1: New USB device found, idVendor=0103, idProduct=0a01, bcdDevice= 1.03
[  652.881153] usb 2-1: New USB device strings: Mfr=1, Product=10, SerialNumber=3
[  652.888488] usb 2-1: SerialNumber: 6VEN3N32            
[  652.921042] scsi host1: uas
[  652.944240] usb 2-1: stat urb: status -71
<....>
[  738.803914] scsi 1:0:0:0: tag#5 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD 
[  738.811240] scsi 1:0:0:0: tag#5 CDB: Inquiry 12 00 00 00 24 00
[  738.820676] scsi host1: uas_eh_device_reset_handler start
[  738.959890] usb 2-1: reset high-speed USB device number 58 using orion-ehci
[  739.143295] scsi host1: uas_eh_device_reset_handler success
[  739.155741] usb 2-1: stat urb: status -71
[  739.160953] scsi 1:0:0:0: tag#5 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD 
[  739.168282] scsi 1:0:0:0: tag#5 CDB: Test Unit Ready 00 00 00 00 00 00
[  739.174957] scsi host1: uas_eh_device_reset_handler start
[  739.327867] usb 2-1: reset high-speed USB device number 58 using orion-ehci
[  739.525257] usb 2-1: device firmware changed
[  739.529776] scsi host1: uas_eh_device_reset_handler FAILED err -19
[  739.536110] scsi 1:0:0:0: Device offlined - not ready after error recovery
[  739.544492] usb 2-1: USB disconnect, device number 58
[  739.699921] usb 2-1: new high-speed USB device number 59 using orion-ehci
[  739.889938] usb 2-1: device descriptor read/all, error -71
[  740.031896] usb 2-1: new high-speed USB device number 60 using orion-ehci
[  740.226314] usb 2-1: device descriptor read/all, error -71
[  740.241865] usb usb2-port1: attempt power cycle

In the case above, device is not seen by fdisk -l. However, one USB port is better than zero, but can you please take a look?

Regards,

1000001101000 commented 3 years ago

I believe mine has the same issue. I have a 4GB USB key that I attached to the rear port and attempted to read from but found that I get input/output errors almost immediately, I then moved it to the front port and was able to read the entire thing with an average speed of 14.6 MB/s (which is about right for USB2).

I don't have many ideas of what to look for to correct this, I'll need to give it some thought.

1000001101000 commented 3 years ago

I spent some time looking at buffalo's kernel source and some other resources but haven't found anyhting useful for solving this problem.

I'm not sure how to accurately describe the issue and don't know where to start to try to fix it.

masterlog80 commented 3 years ago

Hello, @1000001101000 and thank you for your effort on this! Well, for me have at least one USB (the front one) working is fine as long as I can connect a disk and make backups. If one day you will find a way to enable the one on the back (and you also mentioned the switch) I will appreciate if you can update this thread! Otherwise, if there is something I can do to help you, please let me to know.

Regards,

masterlog80 commented 3 years ago

Hello @1000001101000 this issue has been open for some time. Do you think it worth for me to be close it at this point?

Regards,

1000001101000 commented 3 years ago

I'm getting ready to start testing devices with Debian 11 in the coming days/weeks, I don't yet know whether it will be possible to support this device on Debian 11 or not. If it doesn't work with Debian 11 we can close the issue as that will probably be the last time I do anything with this device.

If it does work with Debian 11 we can at least test with the latest kernel and see if the issue has somehow been resolved.

masterlog80 commented 3 years ago

Thank you again, @1000001101000 !

1000001101000 commented 2 years ago

@masterlog80 I ran into some nasty issues that prevented me making progress on the Debian 11 work for several months, but I have recently gotten past them all and have published new installers for the armel devices including the LS-QL. I set it up so that the LS-QL defaults to using my custom kernel which includes the patch to enable the USB port for this device.

Let me know if you get a chance to try it out!

masterlog80 commented 2 years ago

Hello @1000001101000, As I am currently using the NAS storing documents for my work, I am unwilling to reinstall the OS on those days, but I may do that as soon as possible. However, just to clarify, the new kernel should support both the USB ports (on the front and back) or just the front one (without the process on previous comment)?

Regards,