Seems there aren't too many RPi users here.

Done.

Powering the RPi and the external IDE HDD from a +5V/30A (obviously over spec'd) did not cause any issues whatsoever.
Nor did I get any over-current change lines in dmesg.

So ...
One of two things: either the wall wart PS I normally use for my RPi 3B+ does not provide a solid +5V/5.1A max or the sum of the RPi and HDD powering up at the same time pulls a bit more power that than for around 1.5s.

A.

Still trying to figure this out.

From what I have read at the RPi forunm, the over-current change output in dmesg is directly related to an underpowered power supply but one thing that sort of stumped me was finding that some people having this issue has official RPi power supplies.

It seems that what is happening here is this:

Getting the over-current change line in dmesg when the external HDD is connected to one of the power supply's USB ports leads me to think that the PS is indeed underpowered, but then the RPi does complete the boot process as if nothing had happened.

If I had not looked throught the dmesg output, I would not have been the wiser.
Like I mentioned before, there have been no indications of power issues: no red light blink or on-screen warnings, even when overclocked and running a severe stress test.

But then, not getting the over-current change line in dmesg when the external HDD is powered from one of the RPi's USB ports sort of does away with the underpowered PS theory.

So, what's up?

I think that the PS is on the edge of being underpowered and having both the RPi and the external HDD draw power at the same time pushes it over that edge for a bit less than 1.5s ...

pi@rpidevuan:~$ sudo dmesg | grep current
--- snip ---
[    3.194560] usb 1-1-port3: over-current change    <--- first over-current event 
--- snip ---
[ 4.570348] usb 1-1.1-port3: over-current change    <--- last over-current event
--- snip ---
pi@rpidevuan:~$ 

... but then recovers as soon as the HDDs spin-up current draw, which could be up to and even over 1.0A, is gone.
And it is for such as short time that the RPi does not throw any warnings.

Powering the HDD from one of the RPi's USB ports has the RPi powering up before it powers up the HDD (1s, 2s?), so then there's no simultaneous power draw from the RPi and the HDD.

I am hacking up an old 360W Sun Microsystems PS that puts out +5V/30A to make a bench power source and will see if I can reproduce the over-current issue while powering the RPi and HDD from there.

Any ideas?

Cheers,

A.

While looking through the dmesg output of the Devuan ascii 2.0.0 ARM64 instalation on my RPi3B+, I came across this bit:

pi@rpidevuan:~$ sudo dmesg | grep current
--- snip ---
[    3.194560] usb 1-1-port3: over-current change
[    3.410266] usb 1-1-port4: over-current change
[    3.746362] usb 1-1-port2: over-current change
[    4.357932] usb 1-1.1-port2: over-current change
[    4.570348] usb 1-1.1-port3: over-current change
--- snip ---
pi@rpidevuan:~$ 

I don't know what this entails ie: it is not a warning or an error and it seems that everything is working properly, specifically access to the HDD where everything but the /boot partition is.
The external IDE HDD is powered through a cable that plugs into one of the charging ports of the power supply I use for the RPi, a second charging port is for the RPi itself and a third one is vacant.

There are no indications of power issues: no blinking red light or on-screen signs, even when overclocked and running a severe stress test.
But I don't want to risk the thingy's power system.

Curiously enough, if I plug the HDD's power cable into one of the RPi's own USB sockets, not only does everything work properly but there is no trace of the over-current change line in dmesg.

pi@rpidevuan:~$ sudo dmesg | grep current
pi@rpidevuan:~$ 

I'd leave things as they are but I do need to have that last USB port available on the RPi for my coffee roasting data logger.
The other USB ports are for kb and mouse and while bluetooth kb+mouse would be an option, I's rather not have to do it.

Any ideas?

Thanks in advance,

A.