On 31/05/2026 23:57, Pancho wrote:I do not understand your comment. I do not understand the relevance of super speed transmission, or possibly I don't understand what the term means. I don't understand client/host.On 5/29/26 04:42, bp@www.zefox.net wrote:I would be surprised if the fault was caused by back powering. TheThe Natural Philosopher <tnp@invalid.invalid> wrote:>On 28/05/2026 16:38, Mike Scott wrote:>On 28/05/2026 16:27, Mike Scott wrote:Some disks with some USB adapters simply do not workthere seems to be no obvious fault with the ssd as such - it was>
working as expected when put into storage, and a scan with badblock -w
is currently at 80% with no errors.
>
I should add, the pi4 is running from the spinner, while checking the
ssd. 89% checked, 0 errors as I write.
>
Also, a second pi4 has the same issue, so it's not a faulty pi4.
>
>
Two thoughts:
>
Try a different USB bridge on the SSD.
Some behave better than others.
>
+1
>
My rpi4 UBS 3 sockets failed, I suspect due to feeding power back into the port from a powered SATA to USB connector.
>
The USB 2 ports still work fine.
>
This USB failure was slow. USB 3failure started as occasional SSD write errors, gradually becoming more regular.
>
It took me a while to diagnose as the problem was intermittent and there was nothing wrong with the disk itself.
superspeed signals are capacitor coupled. The client end of the
connection does not transmit anything until the host has
completed a probe operation to look for the correct termination
resistance at the client end. Therefore there would never
be any attempt at superspeed data transmission if the host was
unpowered.
John
For clarity, the back powering I observed was on powering down my rPi 4. When I removed the standard rPi4 USB power supply the rPi4 would remain powered on. The rPi4 would only power down when the USB/SATA adapter power was disconnected. i.e. In this scenario the rPi4 was being powered by a USB 3 data port.
Les messages affichés proviennent d'usenet.