crazy problem with pi4 and ssd

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

Peal currents may easily exceed USB ability as well

I've got similar issues here but I have not got to the end of that road yet

Boot the Pi from the spinning disk (or an SD card) and connect the SSD to the Pi. See if you can access it and if not, have a look at the kernel log.

Already did - I ran one full pass with baddisk -w which completed with zero errors.

Why don't you tray what Richard suggested?

Two thoughts:

Try a different USB bridge on the SSD. Some behave better than others.

Maybe try different software on the SSD. I've worked quite a bit with FreeBSD, It lets the Pi firmware start u-boot to find the disk. Maybe that'll work or give some opportunity to tinker with the disk probe (changing usb_pgood_delay in uboot.env has been helpful in some cases).

You'd want

hth,

bob prohaska

Never heard of baddisk, what is that?

Anyway from what you’ve said, Linux on the Pi can’t see the SSD during early boot, but can see it when attached to the Pi later. That’s hard to explain, since it’s the same hardware and the same code looking for it in each case.

Just to check, did you run your ‘full pass with baddisk’ _on the Pi_, as requested above?

My bad - I meant 'badblocks'.

Yes.

The problem does look as though it was down to a combo of the ssd plus one particular sata/usb adapter (I have 3). Using dd, I found transfer rates down to <10MB with the ssd and that particular adapter.

The issue does seem to centre around the combo of ssd, that particular adapter, and the pi4. I get decent transfer rates using my desktop with all the adapters; just the pi4 has issues with that one, fine with the other 2.

Anyway, I have a system that has now booted several times without issue, which is great.

Thanks to all for commenting.

Are these three different models, or just three pieces of kit that should be the same but aren't?

It might be useful to the rest of us to know which makes/models or USB/SATA adaptor you have found do work, and with which HDDs/SDDs, and which do not.

I stopped using badblocks when I found it couldn’t handle drives larger than about 4TiB.

I wrote my own utility for doing scans

For writes, I still use dd.

That really sounds like a power or USB controller issue rather than the SSD itself. I've seen some odd Pi 4 storage problems disappear after switching to a different USB-SATA adapter or using a powered USB setup. It might also be worth checking if the SSD firmware is up to date, since some drives seem more sensitive than others on the Pi.

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.

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

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

Hello NY!

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

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!

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?