USB reset/poweroff handling for HDD
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
- Issue type
- Feature
- Clarity
- Needs clarification
- Activity status
- Stale
- Tech stack
- linux
- Domain
- operating-systems
Research direction
Start with the linked forum discussion and the USB_MSD_PWR_OFF_TIME=0 EEPROM setting described in the issue. Trace how USB storage is handled during Raspberry Pi reset and poweroff, then determine whether a graceful HDD sleep or park can occur before power is removed without preventing shutdown.
Written by the indexing model from the issue text.
Description
I previously used a PI3 mainly for retro gaming, so I have some little experience tinkering with it.
Now I just aquired a PI4 to use it as a NAS, with a 2.5" 2TB USB3 HDD powered directly from the PI, fully updated/upgraded/dist-upgraded.
I am powering the PI through the GPIO header, using pins 2+4 for +5V, 6+9 for ground, with thick and short wires (not the regular colored ones which are very thin).
Issue:
On reset or poweroff, the hard drive makes a loud clicking/rattling of the head.
The "Power-Off_Retract_Count" item in the hard disk's SMART info is increasing as I poweroff/reset the PI. If I reboot or poweroff my PC or laptop with the drive connected, there's definitely no clicking, so there seems to be an issue on how the USB ports are handled on reset/poweroff of the PI3+PI4 (and maybe the older ones as well?).
Originally, I had two clicks from the HDD, one right on reset (just when the screen goes blank) and another one while POSTing, I prevented this last click by adding USB_MSD_PWR_OFF_TIME=0 to the EEPROM, but for the one on reset/poweroff I haven't found anything that would prevent it.
What I noticed is that when issuing the reboot/poweroff command, the OS unloads its stuff, and suddenly (while the HDD LED is still blinking rapidly) the reset occurs, like it is not giving the drive some extra time to park its heads gracefully before cutting the power to the ports. This clicking definitely shorts the lifespan of the drive's head. Is this power-reset really needed?
I've seen this mentioned already, here: https://www.raspberrypi.org/forums/viewtopic.php?t=247093 but the solution was of no help to me because I am not booting from SD, so the proposed script can't be run as the HDD can't be umounted till the very end.
But still, I think it is a good idea: send a sleep command to the drive after unloading the OS and just before the reset/poweroff. The sleep command will park the head normally, without the abrupt clicking.
Can this be implemented somehow?
Thanks in advance for any clues!
- Dominant language
- C
- Stars
- 13.2k
- Forks
- 5.5k
- Avg merge
- 2d 21h
- Merged PRs (30d)
- 21
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from raspberrypi/linux
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
raspberrypi/linux#7415 · 2 comments · 1 reaction ·
-
rp1-cfe doesn't forward V4L2_EVENT_SOURCE_CHANGE event from csi-2 sensor driver to userspace app Open
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
raspberrypi/linux#7399 · 1 comment ·
-
Difficulty 1/5 Under an hour Newbie friendliness 82/100
raspberrypi/linux#7357 · 1 comment ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
raspberrypi/linux#7054 · 2 comments ·
-
Difficulty 4/5 3-5 days Newbie friendliness 48/100
raspberrypi/linux#7634 · 8 comments · 1 reaction ·
All issues in raspberrypi/linux
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
zephyrproject-rtos/zephyr#119726 ·
-
[Bounty proposal] fix(web): memory insights count an evening memory on the next day ($25 proposed) Open
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
BasedHardware/omi#15320 ·
-
[adam] AdamNet network read doesn't cap to MAX_ADAM_PACKET_LEN, overflows client receive buffers Open
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
FujiNetWIFI/fujinet-firmware#1649 · 2 comments ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
HarbourMasters/Shipwright#7229 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
riscv-software-src/riscv-isa-sim#2435 · 1 comment ·