-
Notifications
You must be signed in to change notification settings - Fork 62
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Seagate ST2000NM00XX Drive Various Power Management Not Supported #155
Comments
Hi @andersonsmith, I think the reason you are getting this message is because it did not detect the device as a SCSI drive type (It is saying An alternative to The other thing I think can help me figure out where this bug is coming from is the output from |
Oh, one more thing you can do to workaround the |
Thanks for the replies. Using Regarding the info dump, here it is:
|
This bug has been very difficult to locate so far walking through the code with the information you have shared so far. Can you run this command line and share the output with me? This will run with a lot of verbose output showing me all the command issued and all the data transfers to and from the drive for me to validate manually to see if something else is going on unexpectedly. |
Where would I find that error message? I ran the command with and without |
Thank you for the logs! Looking through the output with --forceSCSI I see the command that is issued (request sense) to check the power state and it is just reporting a normal "good" status. You can try spinning the drive down, then trying |
Fixing a bug that can occur for some devices where the drive_type does not end up being set at all and is left as "UNKNOWN". Many of the upper layers are expecting ATA, SCSI, or NVMe and if left as unknown it requires forcefully setting the drive type. By setting it at this low-level it corrects this behavior without other workarounds by users [Seagate/openSeaChest#155] Signed-off-by: Tyler Erickson <tyler.erickson@seagate.com>
… power mode Adding in issuing a test unit ready command to try and determine if the drive is in a low-power mode by checking if the sense data reports a need for a spin-up command. [Seagate/openSeaChest#155] Signed-off-by: Tyler Erickson <tyler.erickson@seagate.com>
Pulling in updates for setting drive type correctly in low-level OS specific code. Pulling in update to getting SAS power mode via test unit ready [#155] Signed-off-by: Tyler Erickson <tyler.erickson@seagate.com>
Can you give the attached build a try and let me know if it works for you to show standby? |
Output attached. When I check with Should an asterisk be shown with each timer in |
Thanks for the log again!
Yeah, even querying the settings can potentially spin up a disk. It depends if the disk stores the settings on the media or in flash or RAM. It could also be some other system activity (even something you are not triggering directly, but the OS decides it needs something from the device). One other thing I have observed in the past is depending on how the drive's handle is opened in Linux, that can cause the drive to spin up. One other thing that may factor into how this is working is the drive firmware. In your case the firmware string I see indicates a customer unique firmware and sometime those have customizations that may cause some changes from the default behavior of OEM code. I don't know of any specific changes to power settings on this code, but I have not worked with it a lot. I think most likely it is spinning back up due to querying the mode page for the current settings or some other background activity from the OS. SAS drives also have one field that allows specifying preference between background tasks and power modes which could be another part of it. openSeaChest_PowerControl does not currently have a way to toggle this, but I can look into this as part of troubleshooting this issue. We can also try flipping it using openSeaChest_Configure's options to change a mode page with some raw field info if needed.
Yes, that should be changing. I'm reviewing more of the code before I push the fix, but I will share that for you to check out as well. |
…id output Fixing how the VPD and Mode pages are read for EPC drives. Standby Y and Z were mixed up in a bitfield which resulted in incorrect output. There was a second bug where the mode page header was not taken into account so the standby timer values were not correctly accessed and causing invalid results. [Seagate/openSeaChest#155] Signed-off-by: Tyler Erickson <tyler.erickson@seagate.com>
…dby timers [#155] Signed-off-by: Tyler Erickson <tyler.erickson@seagate.com>
Can you give these updated builds a test to see if it fixes the asterisk in the EPC settings? |
Thanks for the deep dive on this one! Can confirm that the asterisk is showing in the EPC settings output now. I assume you are referring to this output from
Specifically thinking of the top line? I assume that it is currently set to power management rather than background. Also figured that the firmware is because these drives are Dell drives so appear to be specific firmware. Some settings seem to be locked such as the background media scan. Does not appear to be editable. Same with the power management bias. |
Thanks for reporting that fixed the asterisk!
Yes, the A firmware may also set something to
This could be the customer specific firmware or just that the firmware at that time did not have a way to support changing that field. I don't know what the STDOEM firmware would do on this drive so I cannot confirm in this case. One other thing I think you may find helpful for figuring out if your drive is going into these low power modes or not is that in If you think it would be helpful to put the PM_BG output into openSeaChest, let me know and I will look into that too. |
Thanks for the suggestion. Looks to me like it's having trouble getting beyond
|
Fixing a bug that can occur for some devices where the drive_type does not end up being set at all and is left as "UNKNOWN". Many of the upper layers are expecting ATA, SCSI, or NVMe and if left as unknown it requires forcefully setting the drive type. By setting it at this low-level it corrects this behavior without other workarounds by users [Seagate/openSeaChest#155] Signed-off-by: Tyler Erickson <tyler.erickson@seagate.com>
… power mode Adding in issuing a test unit ready command to try and determine if the drive is in a low-power mode by checking if the sense data reports a need for a spin-up command. [Seagate/openSeaChest#155] Signed-off-by: Tyler Erickson <tyler.erickson@seagate.com>
…id output Fixing how the VPD and Mode pages are read for EPC drives. Standby Y and Z were mixed up in a bitfield which resulted in incorrect output. There was a second bug where the mode page header was not taken into account so the standby timer values were not correctly accessed and causing invalid results. [Seagate/openSeaChest#155] Signed-off-by: Tyler Erickson <tyler.erickson@seagate.com>
No problem! Thanks for reporting this issue. I'm currently working on writing up Wiki pages to not only help with openSeaChest use but also to help educate on how drives and their features work. |
I have made a patch release v24.08.1 that fixes changing EPC settings and the SCSI drive detection. edit: My earlier comment was about another issue I missposted so you can ignore that 😄 |
Hello, thanks for the work on this toolset. I have a system running 8 seagate SAS drives and cannot get spindown to work. I first worked with sdparm and would see it bouncing in and out of idle. I was hoping to use this to monitor the timer and see if it's getting passed idle_a. The drive manuals for the three models I have all say they support PowerChoice and have the 3 idle states as well as 2 standby states. When polling the drives, I get the following message returned.
I have verified that EPC is enabled, so I'm not sure exactly what to do next.
For reference, the drives are all connected through a SAS3008 HBA flashed to IT mode. The HBA is integrated into a Gigabyte MD70 motherboard. The host is Proxmox running ZFS on the drives.
Please let me know if I've missed anything. Thanks again.
The text was updated successfully, but these errors were encountered: