On 6/1/26 10:35, John R Walliker wrote:

On 31/05/2026 23:57, Pancho wrote:

On 5/29/26 04:42, bp@www.zefox.net wrote:

The Natural Philosopher <tnp@invalid.invalid> wrote:

On 28/05/2026 16:38, Mike Scott wrote:

On 28/05/2026 16:27, Mike Scott wrote:

there 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.

Some disks with some USB adapters simply do not work

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.

I would be surprised if the fault was caused by back powering.ÿ The 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

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.

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.

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 31/05/2026 23:57, Pancho wrote:

My rpi4 UBS 3 sockets failed, I suspect due to feeding power back into
the port from a powered SATA to USB connector.

I use a Pi for a PVR, recording TV programmes to a spinning USB HDD that
is connected to a powered USB hub (so the HDD is not being powered by
the Pi's USB).

When I used a Pi3, this worked perfectly. When I switched to using a
Pi4, with the same HDD and hub, the Pi consistently hung very early in
the boot process. As soon as I unplugged the hub from the Pi (or removed
the hub's PSU) the Pi continued the boot process. (*)

It was a problem mainly if there had been a power cut and the power to
both the Pi and the hub was turned on at the same time (when the power
came back).

Someone suggested back-powering might be the cause, so I made up a
special cable which had its +5V line cut and connected it between the Pi
and the hub. Sadly this made no difference.

Powering the HDD from the Pi's power, via USB, worked fine - but I was
uneasy about drawing so much current from the Pi's PSU in case the
voltage ever sagged to the point that the Pi started to misbehave.

I solved the problem by changing to use a SATA HDD in a caddy that had a powered SATA-USB interface.


So the Pi4 seems to be more sensitive to powered devices than the Pi3.
I'm not sure about the Pi5 as I've only used USB-powered SD cards as
slave drives.



All of this is talking about an HDD that is used as a data disk. I still
boot off an SD card plugged into the Pi's motherboard, in the standard way.



(*) I forget how far the boot got before it hung. It might have been
before there was *any* image on a monitor connected to the HDMI port,
which isn't a great deal of help...

--- PyGate Linux v1.5.16
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Hello NY!

12 Jun 26 20:58, you wrote to all:

On 31/05/2026 23:57, Pancho wrote:

My rpi4 UBS 3 sockets failed, I suspect due to feeding power back
into the port from a powered SATA to USB connector.

I use a Pi for a PVR, recording TV programmes to a spinning USB HDD
that is connected to a powered USB hub (so the HDD is not being
powered by the Pi's USB).

When I used a Pi3, this worked perfectly. When I switched to using a
Pi4, with the same HDD and hub, the Pi consistently hung very early in
the boot process. As soon as I unplugged the hub from the Pi (or
removed the hub's PSU) the Pi continued the boot process. (*)

It was a problem mainly if there had been a power cut and the power to
both the Pi and the hub was turned on at the same time (when the
power came back).

Someone suggested back-powering might be the cause, so I made up a
special cable which had its +5V line cut and connected it between the
Pi and the hub. Sadly this made no difference.

Powering the HDD from the Pi's power, via USB, worked fine - but I was
uneasy about drawing so much current from the Pi's PSU in case the
voltage ever sagged to the point that the Pi started to misbehave.

I solved the problem by changing to use a SATA HDD in a caddy that had
a powered SATA-USB interface.

So the Pi4 seems to be more sensitive to powered devices than the Pi3.
I'm not sure about the Pi5 as I've only used USB-powered SD cards as
slave drives.

All of this is talking about an HDD that is used as a data disk. I
still boot off an SD card plugged into the Pi's motherboard, in the
standard way.

(*) I forget how far the boot got before it hung. It might have been
before there was *any* image on a monitor connected to the HDMI port,
which isn't a great deal of help...

I have a pi3 and had a 4 and for both use a secondary Power adaptor where for the 4 bought a laptop adaptor with the correct power outputs.

The 3 uses a HDD and the 4 used a SSD but the adaptor for it will power a HDD.

Basically the supplied power adaptors for these units is does not have enough grunt for the power requirements i.e., amps etc.

Vincent


--- Mageia Linux v9 X64/Mbse v1.1.7/GoldED+/LNX 1.1.5-b20240604
* Origin: Air Applewood, The Linux Gateway to the UK & Eire (2:250/1)

On Fri, 12 Jun 2026 20:58:07 +0100, NY wrote:

When I used a Pi3, this worked perfectly. When I switched to using a
Pi4, with the same HDD and hub, the Pi consistently hung very early
in the boot process. As soon as I unplugged the hub from the Pi (or
removed the hub's PSU) the Pi continued the boot process. (*)

Did it matter when in the process the drive was mounted?

--- PyGate Linux v1.5.16
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 13/06/2026 03:55, Lawrence D?Oliveiro wrote:

On Fri, 12 Jun 2026 20:58:07 +0100, NY wrote:

When I used a Pi3, this worked perfectly. When I switched to using a
Pi4, with the same HDD and hub, the Pi consistently hung very early
in the boot process. As soon as I unplugged the hub from the Pi (or
removed the hub's PSU) the Pi continued the boot process. (*)

Did it matter when in the process the drive was mounted?

I mounted by means of an entry in the fstab, so it's whenever that happens.

The line was of the form

UUID=F45429CC54299282 /srv/ext ntfs defaults,umask=000,nofail, x-systemd.device-timeout=30 0 0

That's all one line, irrespective of where Thunderbird has wrapped it!


--- PyGate Linux v1.5.16
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Sat, 13 Jun 2026 23:40:48 +0100, NY wrote:

On 13/06/2026 03:55, Lawrence D?Oliveiro wrote:

On Fri, 12 Jun 2026 20:58:07 +0100, NY wrote:

When I used a Pi3, this worked perfectly. When I switched to using
a Pi4, with the same HDD and hub, the Pi consistently hung very
early in the boot process. As soon as I unplugged the hub from the
Pi (or removed the hub's PSU) the Pi continued the boot process.
(*)

Did it matter when in the process the drive was mounted?

I mounted by means of an entry in the fstab, so it's whenever that
happens.

If you made it a noauto mount, then the recognition of the drive would
still take place at boot time, but it would not actually mount at that
point. Would it still freeze then?

--- PyGate Linux v1.5.16
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)