Pi3B+ : USB+ethernet file transfer problem #2449
Comments
|
Having same strange issues with Pi3B+ [1] [2] IMO it's network driver (lan78xx) related or the usb host driver does not handle usb transfers correctly. After switching from eth to wlan, everything is ok [1] Was never able to make an 3GB image backup (root fs is on external usb disk) over network (kernel 4.9, 4.14 and 4.15 tested). Same configuration works on an older Pi3B without any issues [2] When root fs is on iSCSI target, got massive kernel OOPS when using kernel 4.14.27+. After switching to 4.9.87+, ethernet connection was better (no kernel OOPS), but maybe still not stable (more testing needed). Kernel 4.15.10+ not tested |
|
I did another test. Now I am back with the official kernel of the raspbian stretch : 4.9.80-v7, and it is working up to now. |
|
I've got the same problem here... Trying to transfer large files over ethernet fails after a minute or so... Fine on Wifi... However, when I try to downgrade to 4.9.80-v7, I get four flashing green lights on the PI3B+... I can take the card out and plug it into a Pi2 and it boots up just fine... I then have to re-update the firmware and swap everything back to the Pi3B+... Frustrating... |
|
Is this bug related to #2446? If so, then the forthcoming kernel 4.14.28 should fix it. Reverting to an old kernel may be a temporary solution, but only for advanced users. Are other distros affected: xbian, osmc, LibreELEC? At least we know that OSMC used pre-production units, so may be they included a fix/workaround to this problem. I have 10 days to decide to return the RPi 3B+, so I want to start with a working Ethernet or just return the unit unopened. |
IMO there is a good chance to solve some strange issues. As already reported, I'm struggling with my Pi3B+ since I got that part. Raspbian seems to work in my testing scenario [1], but XBian was crashing always, sooner or later. The major difference between Raspbian and XBian is, that Rasbian is using ipv6, whereas XBian is using ipv4 (ipv6 is disabled per default), and those patches fixing the ipv4 stack. After enabling tcp6 on XBian, my test seems so finish successfully. [1] Root fs on usb disk (60GB), mounting Samba share on my server to /mnt, and then run dd if=/dev/sda of=/mnt/test.img bs=1M status=process. Raspbian succeeded, XBian crashes always in different ways: kernel oops, kernel panic of just completely freezed. |
|
If you have a Linux target machine, can you try running this one-liner (you'll need to change the login credentials for the target): I've had that running overnight and it's approaching 2TB transferred without issue. The channel is encrypted, so the 29.4MB/s (235Mb/s) it's achieving isn't bad. If that's solid, switch to: Then: |
|
@pelwell Conclusion: [1] That backup is using btrfs send/receive, sends all local btrfs subvolumes (located on external USB disk) to an image mounted on a network share (cifs of nfs). |
For you, apparently, but not for me - that's why I'm trying to be methodical and work out which step is causing the problem. |
|
@mkreisl Out of curiosity, could you possibly try using sshfs instead of CIFS or NFS? It's a FUSE module instead of a native filesystem driver, and it uses a completely different (and much more efficient) protocol on-the-wire, so it may work even though CIFS and NFS aren't. |
Those basic tests you are running does cause the issue. IMO many many data in and out of the USB is causing the problem. That's the main difference between Pi3B nd Pi3B+, Pi3B has one usb hub, and Pi3B+ has two: Pi3B: Pi3B+: |
|
@Ferroin Good idea, I'll test it. Takes some time, have to modify the backup script |
|
@Ferroin sshfs doesn't make a difference, Pi3B+ dying with kernel Oops again (Pi3B works like a charm) ... and dmesg reports |
|
If you have vcgencmd, please report the output of |
|
Hmm, that's interesting... All of the stack traces in those kernel OOPS messages implicate absolutely nothing from the networking stack, they've just got generic core kernel stuff and VFS layer functions referenced. The complaint about a kernel NULL pointer dereference at a very low virtual address is also somewhat suspicious. Stuff like that is usually indicative of either hardware failure, or a very poorly behaved kernel driver scribbling on memory locations it shouldn't be touching. |
I know, could it be that corrupted data read from usb disk caused this? |
|
'Ported' the backup script to Raspbian, an run it there to backup one of my btrfs partition. Similar result, did not finished. btrfs send/receive stucks, nothing in logs. Tested with original 4.14.27-v7+ kernel and my 4.15.10+ kernel, and of course, backup was running successful on Pi3B |
|
Thanks - that rules out a power supply issue. |
Already tried different PSU's, usually using brand new 2.5A PSU for Pi3B+ and an older one (2A) for Pi3B |
|
Yes, so you said, but I'd rather hear it from the Pi. |
|
@pelwell Btw, I have similar issues if root fs is on iSCSI target and no usb drive is connected and used. |
|
@pelwell @Ferroin Btw, system (root partition) was cloned from usb partition to sd-card using same backup procedure and ran without any issues. |
|
Have you got another Pi3B+ you can try this on. It really is very bizarre, and bizarre always makes me think HW fault. |
No, unfortunately not |
|
It doesn't feel like a hardware fault to me - if so, you would expect to see it on a stock Raspbian kernel as well, and so far I don't think we have. |
Already posted. It happens on Raspbian using standard kernel (4.14.27+) as well |
|
Yes, reading your earlier comment again I can see how it means that. Can you try limiting the ARM cores to 1.2GHz by adding the following to config.txt?: |
|
@pelwell getting periodically message like this: The interval is exactly 239s. Any idea where this value comes from. NFS share is mounted as follows |
|
@pelwell |
|
... and it does not depend on kernel version. 4.9.xx producing same issues |
popcornmix
pushed a commit
that referenced
this issue
Mar 27, 2024
TSO seems to be having issues when packets are dropped and the remote end uses Selective Acknowledge (SACK) to denote that data is missing. The missing data is never resent, so the connection eventually stalls. There is a module parameter of enable_tso added to allow further debugging without forcing a rebuild of the kernel. #2449 #2482 Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.org>
popcornmix
pushed a commit
that referenced
this issue
Mar 27, 2024
TSO seems to be having issues when packets are dropped and the remote end uses Selective Acknowledge (SACK) to denote that data is missing. The missing data is never resent, so the connection eventually stalls. There is a module parameter of enable_tso added to allow further debugging without forcing a rebuild of the kernel. #2449 #2482 Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.org>
popcornmix
pushed a commit
that referenced
this issue
Mar 27, 2024
TSO seems to be having issues when packets are dropped and the remote end uses Selective Acknowledge (SACK) to denote that data is missing. The missing data is never resent, so the connection eventually stalls. There is a module parameter of enable_tso added to allow further debugging without forcing a rebuild of the kernel. #2449 #2482 Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.org>
popcornmix
pushed a commit
that referenced
this issue
Apr 3, 2024
TSO seems to be having issues when packets are dropped and the remote end uses Selective Acknowledge (SACK) to denote that data is missing. The missing data is never resent, so the connection eventually stalls. There is a module parameter of enable_tso added to allow further debugging without forcing a rebuild of the kernel. #2449 #2482 Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.org>
popcornmix
pushed a commit
that referenced
this issue
Apr 5, 2024
TSO seems to be having issues when packets are dropped and the remote end uses Selective Acknowledge (SACK) to denote that data is missing. The missing data is never resent, so the connection eventually stalls. There is a module parameter of enable_tso added to allow further debugging without forcing a rebuild of the kernel. #2449 #2482 Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.org>
popcornmix
pushed a commit
that referenced
this issue
Apr 5, 2024
TSO seems to be having issues when packets are dropped and the remote end uses Selective Acknowledge (SACK) to denote that data is missing. The missing data is never resent, so the connection eventually stalls. There is a module parameter of enable_tso added to allow further debugging without forcing a rebuild of the kernel. #2449 #2482 Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.org>
popcornmix
pushed a commit
that referenced
this issue
Apr 8, 2024
TSO seems to be having issues when packets are dropped and the remote end uses Selective Acknowledge (SACK) to denote that data is missing. The missing data is never resent, so the connection eventually stalls. There is a module parameter of enable_tso added to allow further debugging without forcing a rebuild of the kernel. #2449 #2482 Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.org>
popcornmix
pushed a commit
that referenced
this issue
Apr 11, 2024
TSO seems to be having issues when packets are dropped and the remote end uses Selective Acknowledge (SACK) to denote that data is missing. The missing data is never resent, so the connection eventually stalls. There is a module parameter of enable_tso added to allow further debugging without forcing a rebuild of the kernel. #2449 #2482 Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.org>
popcornmix
pushed a commit
that referenced
this issue
Apr 16, 2024
TSO seems to be having issues when packets are dropped and the remote end uses Selective Acknowledge (SACK) to denote that data is missing. The missing data is never resent, so the connection eventually stalls. There is a module parameter of enable_tso added to allow further debugging without forcing a rebuild of the kernel. #2449 #2482 Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.org>
popcornmix
pushed a commit
that referenced
this issue
Apr 16, 2024
TSO seems to be having issues when packets are dropped and the remote end uses Selective Acknowledge (SACK) to denote that data is missing. The missing data is never resent, so the connection eventually stalls. There is a module parameter of enable_tso added to allow further debugging without forcing a rebuild of the kernel. #2449 #2482 Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.org>
popcornmix
pushed a commit
that referenced
this issue
Apr 18, 2024
TSO seems to be having issues when packets are dropped and the remote end uses Selective Acknowledge (SACK) to denote that data is missing. The missing data is never resent, so the connection eventually stalls. There is a module parameter of enable_tso added to allow further debugging without forcing a rebuild of the kernel. #2449 #2482 Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.org>
popcornmix
pushed a commit
that referenced
this issue
Apr 23, 2024
TSO seems to be having issues when packets are dropped and the remote end uses Selective Acknowledge (SACK) to denote that data is missing. The missing data is never resent, so the connection eventually stalls. There is a module parameter of enable_tso added to allow further debugging without forcing a rebuild of the kernel. #2449 #2482 Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.org>
popcornmix
pushed a commit
that referenced
this issue
Apr 29, 2024
TSO seems to be having issues when packets are dropped and the remote end uses Selective Acknowledge (SACK) to denote that data is missing. The missing data is never resent, so the connection eventually stalls. There is a module parameter of enable_tso added to allow further debugging without forcing a rebuild of the kernel. #2449 #2482 Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.org>
popcornmix
pushed a commit
that referenced
this issue
Apr 29, 2024
TSO seems to be having issues when packets are dropped and the remote end uses Selective Acknowledge (SACK) to denote that data is missing. The missing data is never resent, so the connection eventually stalls. There is a module parameter of enable_tso added to allow further debugging without forcing a rebuild of the kernel. #2449 #2482 Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.org>
jai-raptee
pushed a commit
to jai-raptee/iliteck1
that referenced
this issue
Apr 30, 2024
TSO seems to be having issues when packets are dropped and the remote end uses Selective Acknowledge (SACK) to denote that data is missing. The missing data is never resent, so the connection eventually stalls. There is a module parameter of enable_tso added to allow further debugging without forcing a rebuild of the kernel. raspberrypi/linux#2449 raspberrypi/linux#2482 Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.org>
jai-raptee
pushed a commit
to jai-raptee/iliteck1
that referenced
this issue
Apr 30, 2024
TSO seems to be having issues when packets are dropped and the remote end uses Selective Acknowledge (SACK) to denote that data is missing. The missing data is never resent, so the connection eventually stalls. There is a module parameter of enable_tso added to allow further debugging without forcing a rebuild of the kernel. raspberrypi/linux#2449 raspberrypi/linux#2482 Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.org>
jai-raptee
pushed a commit
to jai-raptee/iliteck1
that referenced
this issue
Apr 30, 2024
TSO seems to be having issues when packets are dropped and the remote end uses Selective Acknowledge (SACK) to denote that data is missing. The missing data is never resent, so the connection eventually stalls. There is a module parameter of enable_tso added to allow further debugging without forcing a rebuild of the kernel. raspberrypi/linux#2449 raspberrypi/linux#2482 Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.org>
jai-raptee
pushed a commit
to jai-raptee/iliteck1
that referenced
this issue
Apr 30, 2024
TSO seems to be having issues when packets are dropped and the remote end uses Selective Acknowledge (SACK) to denote that data is missing. The missing data is never resent, so the connection eventually stalls. There is a module parameter of enable_tso added to allow further debugging without forcing a rebuild of the kernel. raspberrypi/linux#2449 raspberrypi/linux#2482 Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.org>
jai-raptee
pushed a commit
to jai-raptee/iliteck1
that referenced
this issue
Apr 30, 2024
TSO seems to be having issues when packets are dropped and the remote end uses Selective Acknowledge (SACK) to denote that data is missing. The missing data is never resent, so the connection eventually stalls. There is a module parameter of enable_tso added to allow further debugging without forcing a rebuild of the kernel. raspberrypi/linux#2449 raspberrypi/linux#2482 Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.org>
jai-raptee
pushed a commit
to jai-raptee/iliteck1
that referenced
this issue
Apr 30, 2024
TSO seems to be having issues when packets are dropped and the remote end uses Selective Acknowledge (SACK) to denote that data is missing. The missing data is never resent, so the connection eventually stalls. There is a module parameter of enable_tso added to allow further debugging without forcing a rebuild of the kernel. raspberrypi/linux#2449 raspberrypi/linux#2482 Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.org>
jai-raptee
pushed a commit
to jai-raptee/iliteck1
that referenced
this issue
Apr 30, 2024
TSO seems to be having issues when packets are dropped and the remote end uses Selective Acknowledge (SACK) to denote that data is missing. The missing data is never resent, so the connection eventually stalls. There is a module parameter of enable_tso added to allow further debugging without forcing a rebuild of the kernel. raspberrypi/linux#2449 raspberrypi/linux#2482 Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.org>
popcornmix
pushed a commit
that referenced
this issue
May 2, 2024
TSO seems to be having issues when packets are dropped and the remote end uses Selective Acknowledge (SACK) to denote that data is missing. The missing data is never resent, so the connection eventually stalls. There is a module parameter of enable_tso added to allow further debugging without forcing a rebuild of the kernel. #2449 #2482 Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.org>
popcornmix
pushed a commit
that referenced
this issue
May 13, 2024
TSO seems to be having issues when packets are dropped and the remote end uses Selective Acknowledge (SACK) to denote that data is missing. The missing data is never resent, so the connection eventually stalls. There is a module parameter of enable_tso added to allow further debugging without forcing a rebuild of the kernel. #2449 #2482 Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.org>
popcornmix
pushed a commit
that referenced
this issue
May 20, 2024
TSO seems to be having issues when packets are dropped and the remote end uses Selective Acknowledge (SACK) to denote that data is missing. The missing data is never resent, so the connection eventually stalls. There is a module parameter of enable_tso added to allow further debugging without forcing a rebuild of the kernel. #2449 #2482 Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.org>
popcornmix
pushed a commit
that referenced
this issue
May 20, 2024
TSO seems to be having issues when packets are dropped and the remote end uses Selective Acknowledge (SACK) to denote that data is missing. The missing data is never resent, so the connection eventually stalls. There is a module parameter of enable_tso added to allow further debugging without forcing a rebuild of the kernel. #2449 #2482 Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.org>
popcornmix
pushed a commit
that referenced
this issue
May 28, 2024
TSO seems to be having issues when packets are dropped and the remote end uses Selective Acknowledge (SACK) to denote that data is missing. The missing data is never resent, so the connection eventually stalls. There is a module parameter of enable_tso added to allow further debugging without forcing a rebuild of the kernel. #2449 #2482 Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.org>
popcornmix
pushed a commit
that referenced
this issue
May 28, 2024
TSO seems to be having issues when packets are dropped and the remote end uses Selective Acknowledge (SACK) to denote that data is missing. The missing data is never resent, so the connection eventually stalls. There is a module parameter of enable_tso added to allow further debugging without forcing a rebuild of the kernel. #2449 #2482 Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.org>
popcornmix
pushed a commit
that referenced
this issue
Jun 3, 2024
TSO seems to be having issues when packets are dropped and the remote end uses Selective Acknowledge (SACK) to denote that data is missing. The missing data is never resent, so the connection eventually stalls. There is a module parameter of enable_tso added to allow further debugging without forcing a rebuild of the kernel. #2449 #2482 Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.org>
popcornmix
pushed a commit
that referenced
this issue
Jun 3, 2024
TSO seems to be having issues when packets are dropped and the remote end uses Selective Acknowledge (SACK) to denote that data is missing. The missing data is never resent, so the connection eventually stalls. There is a module parameter of enable_tso added to allow further debugging without forcing a rebuild of the kernel. #2449 #2482 Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.org>
popcornmix
pushed a commit
that referenced
this issue
Jun 3, 2024
TSO seems to be having issues when packets are dropped and the remote end uses Selective Acknowledge (SACK) to denote that data is missing. The missing data is never resent, so the connection eventually stalls. There is a module parameter of enable_tso added to allow further debugging without forcing a rebuild of the kernel. #2449 #2482 Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.org>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
and others
Hi,
I have problems while transferring files from an USB external HDD or USB flash drive connected on the new RPi 3B+ to another computer via SFTP or samba. After a random amount of data transfered, the transfer rate drop to 0 and stay like that for at least 30 min ( I canceled the transfer after that time).
I cannot see any error on the standard raspbian system logs. I am running raspbian stretch with the last updates, I also did a firmware upgrade with rpi-update.
The RPi 3B+ is powered with an official raspberry power supply (2.5A) and I tried with a spare one.
I tried to give more power with an external power supply for the USB HDD without any change, but like I got the same problem with an USB flash drive, I don't expect a power issue or ?
I tried to transfer files with thunar, pcmanfm, scp or rsync. rsync is the only one working, but with a strong fluctuation of the transfer rate (from 0 to 20Mo/s). scp tell me that the file is "stalled" and stop any progress.
If I start the same SD card with a RPi 3B (not plus) the file transfer is working like a charm ( I used it for almost 3 years like that).
I followed tips from this link without successI having no problems during ssh sessions or with vnc.
Any ideas ?
The text was updated successfully, but these errors were encountered: