I have also tried it on my other RPi 3B (non-plus) as described above and did not have any problem. I believe the problem lies in some OS resource being starved/saturated too much in this particular config, considering the 3B (non-plus) can push 11 MiB/s over the ethernet, while RPi 3B+ can push twice as much.
Just for the record, all the tests I did were transfers from RPi to my desktop, so the disk was only in reading mode.
Ok, is there any unusual cluster size used on the NTFS? You can check by umount the mount point and try ntfsinfo -m /dev/sda1 or so.
Here I used default 4KB cluster size.
It would be interesting if the bandwidth of the 3B+ could be artificially limited to 100bt and check whether this would change anything.
Here is the ntfsinfo output: https://paste.osmc.tv/uwupolowug
I believe it is pretty much at defaults from Windows 7 disk manager.
If youāve simply moved the SD card from the Pi3B+ to the 3B (non-plus), the kernel will be the same, as will be the drivers. In such a situation, this would suggest to me some kind of issue with driver/firmware, given that there are hardware differences between the 3B and 3B+. There is another thread where iSCSI is reported to work on a Pi3B but not on a 3B+, again suggesting some kind of driver/firmware issue.
This is perfectly possible, but there is also a fact that ext4 is working fine. If there was a firmware problem (e.g. in USB or network interface) it must also somehow be exposed only on ntfs partition and not on ext4 partition.
We really donāt have much to go on.
What do we know:
Whatās not clear to me (forgive me if Iāve missed it):
I tried one old ānonameā pendrive of 1 GB with ntfs and was able to stall it after several attempts, but I do not really consider it conclusive, since at that time I was also observing āUnder-voltage detected! (0x00050005)ā from kernel in journalctl, but I also had all the other things connected (SSD, tuner).
Besides, I believe that USB controller/bridge also has an impact so testing arbitrary pen drives with whatever outcomes, I will not know how to interpret the results. Plus Samsung EVO 850 even when connected through USB/SATA bridge is completely different class from any pendrive.
The only test I found conclusive is the one I did with only the SSD connected, and only using its either ext4 or ntfs partitions.
The pendrive test should have given us a clearer picture of whether the issue is confined to the Samsung SSD. Unfortunately, the under-voltage condition has effectively invalidated that test. I thought youād already moved the SSD to an external power supply.
If youāre gong to retry the test, Iād recommend you do it on the most limited configuration possible. Having the SSD and a TV tuner attached at the same time introduces too many variables.
I have run a new test, using 1GB pendrive formatted with NTFS and having all the other peripherals disconnected. I was transferring two files (430 and 460 MB) back and forth and after 5 transfers I was able to reproduce the problem, i.e. stalling the download, and since then it was happening every time when I initiated the download.
After that I reformatted the pendrive to ext4 and did the same test and was not able to replicate the problem even after 9 transfers.
So, it looks to be isolated to the Pi 3B+. As far as I can see there are quite similiar problems known and discussed doing parallel stress on USB and gigabit LAN of the 3B+, see https://github.com/raspberrypi/linux/issues/2449.
@risa2000 Scrolled through this topic from top to down and see that no standard logs where requested all the time. I think it could help to understand your issue by checking your kernel log for such kernel oops messages.
After reboot and another stall recurrence could you share the URL(s) from
dmesg|paste-log
and
journalctl --no-pager|paste-log
Thx in advance,
Thanks for the update. So we can add to the list of things that we know:
What we still donāt know (taken from post #26 above):
As @JimKnopf has already pointed out, there is a long thread on GitHub where people are discussing a similar issue: things work just fine on the Pi3 but fail on the 3+. One post caught my eye from JamesH65 on Mar 24:
Whatever it is, we are looking in to it. My suspicion is that its a driver
issue that we will figure out, although sometimes these things can take a
while. On the 3B, there was a bug in the smsc95xx driver, matched with a
bug in the brcmfmac software, that we didnāt get to the bottom off for
about a year - but its was a difficult bug to reproduce. Neigher pieces of
software written by us incidentally, in much the same way that the lan78xx
driver or the chip firmware, which is presumably at fault here, wasnāt
written by us either.
The reason I did not post any log was that in correct scenario, there was nothing suspicious in the log.
For the record I post two logs I recorded today (which do not show much):
dmesg https://paste.osmc.tv/kenicotuvu
journalctl https://paste.osmc.tv/bahowivopa
However during the tests I encountered strange behavior:
I run the tests with the SSD powered from USB, but I got āunder-voltageā message in the kernel log when I simultaneously transferred files over SFTP and tvheadend started tuning both tuners to grab EPG.
So decided to disconnect the tuners and reconnect the SSD via self-powered USB/SATA bridge, which I do not use normally, because it is quite cumbersome to run. To avoid any additional interaction I also disabled both kodi (mediacenter) and tvheadend services from starting up at boot. This led to surprising result, I was no longer able to trigger the issue.
Then I decided to start tvheadend and kodi as usual, just without the tuners (still keeping SSD on the powered bridge). There I was able to reproduce the problem with stalling the transfer relatively fast. And from this test are the logs posted above.
But then I was able to stall the SFTP transfer also from ext4 partition. Which was supposed to work before.
So now I am more inclined to believe that there is actually not an important difference between ext4 and ntfs behavior, I was probably just lucky to not replicate it on ext4 until now. It also seems that the problem is sensitive to system resources (availability). And the means to replicate it is not always straightforward, like sometimes I had to run several attempts to stall it and sometimes (as in case 2) above) I was not able to reproduce it.
My personal feeling is that this is either driver or HW issue related to USB hub in RPi (which drives both network and USB ports) and which gets stalled if some OS resource is not available (or available enough).
I have read the thread and it looks like my issue, thanks for pointing it out. I posted the references there as well.
Now it seems there have been some progress on the topic according to the github thread. They suggested running rpi-update, but this is discouraged by OSMC , so I wonder what is the best strategy? Should I run rpi-update nonetheless or wait for official OSMC update?
Iām monitoring the GitHub issue, and incorporating changes as they are made available. I will likely release an update soon; and straight afterwards, Iāll then make further improvements available via staging.
Can you also test with another filesystem, there seems to be a separate issues with NTFS at the moment.
Sam
Ok. I will wait for your release. Once available, I could test NTFS and ext4 easily, as I have both on the same drive. However ext4 was much harder to stall.
Thatās in line with what Iād expect.
There are a couple of commits from a few hours ago over on that GitHub thread. Looks promising! 