LinuxQuestions.org - Struggling with USB and Pi3

- Slackware - ARM (https://www.linuxquestions.org/questions/slackware-arm-108/)

- - Struggling with USB and Pi3 (https://www.linuxquestions.org/questions/slackware-arm-108/struggling-with-usb-and-pi3-4175683401/)

Struggling with USB and Pi3

Hi all,
while it's not Slackware related, I'm writing here trying to find a solution.
I have a Pi3b ( but had this problem also on a Pi3b+ ) whee I have attached an external 1Tb HD to use as NFS tsorage for other servers.

It always keep disconnecting and this obviuosly lead to non usable nfs share and sometimes to ext4 corruption.

The disk is connected to a powered USB HUB that I think is THE part of problem but cannot identify exactly.

I thought that using a powered hub would have fixed the "Undervoltage detected" issue that some times used to appear on my boards, but it seems that the fix is worst than the problem :(

I use the nfs share as backend for backup, so it's quite important to have it rock solid.

I'm starting to think to replace the USB HUB with something tested ( and recommended ) by others.

Do you have any suggestion ?

Thanks in advance

Pierluigi

I have a PI 4 and recently had to return a 2.5" usb case which would work in my laptop, but gave read errors on my Pi. It did have solder bridges between tracks.

My point is that current limits on Pis are probably stricter than on x86 PCs. That said, tell us about the disk. 2.5" or 3.5"? SSD or platter?

Quote:

Originally Posted by Pigi_102 (Post 6173934)

Do you have any suggestion ?

Hi Pigi. If you have another USB-HDD cable try it in place of the one you have now. Some cables are not as reliable as others at delivering the required voltage and you may find a more robust cable removes the 'undervoltage detected' problem.

There have been some user reports that powered hubs can produce the problems you are experiencing on the Raspberry Pi. I haven't had any issues with the powered hubs I have used in the past, but I have had several issues with USB power and data cables.

The disk is a "Toshiba Canvio Basics 1TB Portable External Hard Drive 2.5 Inch USB 3.0"
The hub is a "MEDIACOM HUB USB 2.0 Zero Line"

The disk cable I think it should be fine, as Toshiba is a good name. Maybe the HUB cable could be the problembut I won't bother chaning both if it fix my problem.

What should I look for, when searching for the cables ?

Quote:

Originally Posted by Pigi_102 (Post 6173945)

A Toshiba 1TB 2.5" HDD will draw approx. 3.0 Watts when writing data - I would double that when looking for a USB data/power cable for the RPi3. So, I would look for a cable that's easily capable of carrying 2-2.5 Amps current @ 5 Volts.

[EDIT] If you have a spare PSU for the USB hub try that too. The power could be dipping when there's high demand and that would cause the sort of disconnects you're describing.

The funny thing, Exaga, is that I get some disconnect also when ( I'm sure of this ) there is no NFS activities.
My backups starts at 22.30, and no one other could connect to these machines, but I've seen disconnections also at 12.00 or 16.xx so whene there is no activities at all.

Actually one of my workaround is to run these script:

Code:

#!/bin/bash

/etc/rc.d/rc.nfsd stop

umount /backuppool 

fsck  /backuppool

mount /backuppool

/etc/rc.d/rc.nfsd start

( thus basically do everything is required to draw maximum power from USB :) )

If I issue these commands just before the backups then usually these ( backups ) works.
Instead if I just let things go ( no umount, no fsck no other stuffs ) then I get the problems, as during the day the USB disconnect.

I will try to power the USB HUB with a different power, or find a new PS for the Pi with more amps, and bypass the HUB.

The only hard thing is that for every test I have to move to the remote site where sit the servers :(

Quote:

Originally Posted by Pigi_102 (Post 6174011)

The funny thing, Exaga, is that I get some disconnect also when ( I'm sure of this ) there is no NFS activities.
My backups starts at 22.30, and no one other could connect to these machines, but I've seen disconnections also at 12.00 or 16.xx so whene there is no activities at all.

I will try to power the USB HUB with a different power, or find a new PS for the Pi with more amps, and bypass the HUB.

If you do a Google search for "Toshiba Canvio Basics 1TB Raspberry Pi" there's quite a few users who have faced issues with this external HDD.

Exaga, I've googled for the Toshiba and Raspberry Pi, but found also a lot of users that use this HD quite happly.

Yesterday I had a new "crash" that I already have seen ( on other hard disk ) sometime ago.
Basially, when the CPU is under stress, the Pi loose the whole USB stack ( loosing also the eth0 ).

Part of my backup include doing a bzip2 of weekly backup, for historical purpose.
I moved this bzip2 procedure to Pi, to save some network bandwidth and, as soon as the CPU usage goes high, I gest the following:

Code:

[Sun Oct 11 08:36:50 2020] ------------[ cut here ]------------

[Sun Oct 11 08:36:50 2020] WARNING: CPU: 1 PID: 27097 at fs/fs-writeback.c:2238 __mark_inode_dirty+0x134/0x434

[Sun Oct 11 08:36:50 2020] bdi-block not registered

[Sun Oct 11 08:36:50 2020] Modules linked in: md5 nfsd ipv6 dm_mod brcmfmac brcmutil bcm2835_codec(C) sha256_generic bcm2835_v4l2(C) v4l2_mem2mem bcm2835_mmal_vchiq(C) cfg80211 v4l2_common videobuf2_dma_contig 

videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 rfkill videobuf2_common evdev videodev rtc_ds1307 media raspberrypi_hwmon hwmon vc_sm_cma(C) i2c_bcm2835 uas uio_pdrv_genirq uio fixed

[Sun Oct 11 08:36:50 2020] CPU: 1 PID: 27097 Comm: bzip2 Tainted: G        WC        4.19.80-v7+ #1

[Sun Oct 11 08:36:50 2020] Hardware name: BCM2835

[Sun Oct 11 08:36:50 2020] [<80112174>] (unwind_backtrace) from [<8010d410>] (show_stack+0x20/0x24)

[Sun Oct 11 08:36:50 2020] [<8010d410>] (show_stack) from [<8084004c>] (dump_stack+0xcc/0x110)

[Sun Oct 11 08:36:50 2020] [<8084004c>] (dump_stack) from [<80120eb0>] (__warn.part.3+0xc8/0xe4)

[Sun Oct 11 08:36:50 2020] [<80120eb0>] (__warn.part.3) from [<80120f40>] (warn_slowpath_fmt+0x74/0x90)

[Sun Oct 11 08:36:50 2020] [<80120f40>] (warn_slowpath_fmt) from [<80302e68>] (__mark_inode_dirty+0x134/0x434)

[Sun Oct 11 08:36:50 2020] [<80302e68>] (__mark_inode_dirty) from [<802eda1c>] (generic_update_time+0xec/0x118)

[Sun Oct 11 08:36:50 2020] [<802eda1c>] (generic_update_time) from [<802edf00>] (file_update_time+0x128/0x158)

[Sun Oct 11 08:36:50 2020] [<802edf00>] (file_update_time) from [<8025e3f8>] (__generic_file_write_iter+0xa0/0x1cc)

[Sun Oct 11 08:36:50 2020] [<8025e3f8>] (__generic_file_write_iter) from [<8037c694>] (ext4_file_write_iter+0xfc/0x490)

[Sun Oct 11 08:36:50 2020] [<8037c694>] (ext4_file_write_iter) from [<802d048c>] (__vfs_write+0x124/0x170)

[Sun Oct 11 08:36:50 2020] [<802d048c>] (__vfs_write) from [<802d06c0>] (vfs_write+0xb4/0x1c8)

[Sun Oct 11 08:36:50 2020] [<802d06c0>] (vfs_write) from [<802d09a0>] (ksys_write+0x74/0xe8)

[Sun Oct 11 08:36:50 2020] [<802d09a0>] (ksys_write) from [<802d0a2c>] (sys_write+0x18/0x1c)

[Sun Oct 11 08:36:50 2020] [<802d0a2c>] (sys_write) from [<80101000>] (ret_fast_syscall+0x0/0x28)

[Sun Oct 11 08:36:50 2020] Exception stack(0xaf2c5fa8 to 0xaf2c5ff0)

[Sun Oct 11 08:36:50 2020] 5fa0:                  00001000 009b90c0 00000001 009b90c0 00001000 00000000

[Sun Oct 11 08:36:50 2020] 5fc0: 00001000 009b90c0 76f06fe0 00000004 76e8bbe0 76e8b748 76e8bbe0 00001388

[Sun Oct 11 08:36:50 2020] 5fe0: 009ba0c0 7efe3628 76d9f8e0 76e06940

[Sun Oct 11 08:36:50 2020] ---[ end trace bd1279d2cd660d77 ]---

after that the whole USB stack was gone:

Code:

[Sun Oct 11 08:36:52 2020] smsc95xx v1.0.6

[Sun Oct 11 08:36:52 2020] smsc95xx 1-1.1:1.0 eth0: register 'smsc95xx' at usb-3f980000.usb-1.1, smsc95xx USB 2.0 Ethernet, b8:27:eb:04:78:8e

[Sun Oct 11 08:36:52 2020] usb 1-1.2: new low-speed USB device number 43 using dwc_otg

[Sun Oct 11 08:36:52 2020] usb 1-1.2: New USB device found, idVendor=413c, idProduct=2003, bcdDevice= 3.01

Luckily I had a script that reenable eth0 address so I gained back the connectivity to Pi and could save the dmesg.

This problem was already present sometime ago, with the 5.4.21 kernel ( and that's why I rollback to 4.19.80-v7 ).

I'm still searching a valid power supply to provide enough juice to Pi to be able to exclude USB HUB from the equation. as it could also be part of the problem.

Not sure if, eventually, is a firmware problem.

Pigi

Have you tried switching the script to xz? It should tidy things up. bzip2 is the slowest IMO.

It could be an idea to save some time, but the problem is with the high-CPU/high-usb traffic IMHO, as I already have seen this behavior in other applications...

Before upgrading my Pi to a new Pi4 I used to have a Pi3 and have the same probllem when doing some "dump | scp" operation.

It seems that I have no trouble with the Pi4, but must check a little more.

Pigi

I've changed the power supply, and at the same time I've removed the Usb-HUB from the equation by connecting the disk directly to the board, and leaving the keyboard and other not critical stuff on the hub.
So far so good.
At the end of the week, if everything is fine, I will mark this as solved :)

Thanks to all.

Quote:

Originally Posted by Pigi_102 (Post 6174721)

Before upgrading my Pi to a new Pi4 I used to have a Pi3 and have the same probllem when doing some "dump | scp" operation.

It seems that I have no trouble with the Pi4, but must check a little more.

This reminds me of a problem I had on the RPi2 and 3 with 'makepkg' for the Slackware ARM current sarpi-kernel-source packages (i.e. a very large file size). It would spectacularly crash if I didn't specify '--threads 1' in the command options - usually with an "out of memory" related error or I/O failure. This wasn't a problem on Slackware ARM 14.2 or on my RPi4 which has 4GB RAM. It only occurred with Slackware ARM current on the RPi2 and 3 which has 1GB RAM. Forcing 'makepkg' to work single-thread only was the solution.

Code:

makepkg -l y -c n --threads 1 /path/to/${PKGNAM}.t?z

Probably nothing at all to do with your issue. It just reminded me of the problems I've described when reading your post. :)

I suggest you use autofs so that the drive powers down while it is not in use. You would then be avoiding disconnects and the need to run umount/fsck/mount. The difference between what you have and what autofs provides is a small amount of latency while your drive powers back on for use. Additionally, I suggest connecting the disk directly to the USB port.

Here is an example of autofs, ext4, and nfs: https://opensource.com/article/18/7/...e-Raspberry-Pi

99% of USB hubs are junk (crap, garbage, steaming piles of smelly poo).

In the past I've used an Anker USB 3.0 Aluminum 14-Port Hub with good results running multiple external DVD drives when connected to a Super Micro server USB port. Have never tried a hub connected to RPi's yet. So maybe worth trying one of Anker's USB hubs to see if that helps (they make various models with fewer ports also). No guarantees though ever when a hub is involved.

From lurking on Pi lists, I think the received wisdom is: If you're having usb issues, install a separately powered usb hub of any make/description, and you won't look back.