Wireshark won't help as it won't tell you what process is doing. And decoding the commands will be very difficult.
You probably should send the power down and wait a few seconds before starting the loop. It would seem to be pretty likely that if in the middle of the spin-down *ANY* command that is received causes it to power the disk fully back up and aborts the spin-down. But once the disk is completely spun-down that specific command does not spin the disk back up. In the middle of the spin-down it would appear that the disk is not yet in the certain commands do not cause a spin-up state. This would assume the disk has 2 operational states. When in the spun-up state any command causes a spin-up, once in the spun-down state certain commands don't cause a spin-up. And until the spin-down is completed it would appear it is still in the first state.
On Sat, Mar 27, 2021 at 7:18 AM Patrick O'Callaghan pocallaghan@gmail.com wrote:
On Sat, 2021-03-27 at 09:50 +0800, Ed Greshko wrote:
On 27/03/2021 07:20, Patrick O'Callaghan wrote:
This never happens if I run the script directly from the command line (i.e. the drives power down and stay down).
Clearly the docking unit isn't just doing this flakily on its own. Something is making it happen, and I've no idea how to discover what it is except that it seems to be correlated with systemd in some way.
Just "thinking out loud" here.
When you run the script from the command line it is after you've determined the unmount has happened. How much time do you think elapsed between the actual unmount and running of the script? Do you have a delay between the time inotifywait detects unmount and powering down the drives? If so, does it help if you extend the delay?
The power-down script loops as long as it detects that the drives are spun up (using hdparm -C), since they take few seconds to actually spin down. I can physically see them being spun down, then a couple of seconds later they spin up again, which can only be because something is accessing them. If I then invoke the same power-down script manually, they power down and stay down.
I've now modified the script to run an outer loop three times over the power-down-and-check sequence, which so far seems to do the trick, but it's a real kludge.
I have never used it for this, but wireshark does have the ability to monitor USB. Don't know if that will reveal anything or be of any help.
Only as a last resort. I don't fancy having to learn USB command sequences.
poc _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure