Skip to content
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

Open
andersonsmith opened this issue Sep 2, 2024 · 15 comments
Open
Assignees

Comments

@andersonsmith
Copy link

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.

==========================================================================================
 openSeaChest_PowerControl - openSeaChest drive utilities - NVMe Enabled
 Copyright (c) 2014-2024 Seagate Technology LLC and/or its Affiliates, All Rights Reserved
 openSeaChest_PowerControl Version: 3.6.0-8_0_1 X86_64
 Build Date: Aug 28 2024
 Today: 20240902T091153 User: root
==========================================================================================

/dev/sg7 - ST2000NM0001 - Z1P20M8C - XRBA - UNKNOWN
Showing EPC Settings not supported on this device.

I have verified that EPC is enabled, so I'm not sure exactly what to do next.

       Features Supported:
                Protection Type 1
                Protection Type 2
                Application Client Logging
                Self Test
                Automatic Write Reassignment [Enabled]
                Automatic Read Reassignment [Enabled]
                EPC [Enabled]
                Informational Exceptions [Mode 6]
                Background Media Scan [Enabled]
                Translate Address
                Format Unit
        Adapter Information:
                Adapter Type: PCI
                Vendor ID: 1000h
                Product ID: 0097h
                Revision: 0002h

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.

@vonericsen
Copy link
Contributor

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 UNKNOWN in your output).
I'm not sure why this is not detecting as a SCSI drive type, but this seems to be a software bug so I will debug it to figure out where it went wrong since the rest of the output makes sense.
This is what is also preventing displaying the EPC timer values since it is checking the drive type to figure out how to read it.

An alternative to --spindown is --transitionPower standby or more specifically for EPC --transitionPower standby_z (these should be the same though).
Can you let me know if this works?
This would be good to know as the code paths between spindown and transition power are a little different and it may be better to make them the same if transition power works correctly.

The other thing I think can help me figure out where this bug is coming from is the output from openSeachest_PowerControl -d <handle> --llInfo
That is two lowercase Ls and a capital I for info (short for low-level info).
This will dump a lot of information that openSeaChest reads from /sys to figure out how the drive is attached, the adapter IDs (which read correctly for your output), and some other information that may help me figure out what went wrong and triggered this bug.

@vonericsen vonericsen self-assigned this Sep 3, 2024
@vonericsen
Copy link
Contributor

Oh, one more thing you can do to workaround the UNKNOWN drive issue is to use the --forceSCSI option which will override the drive type detection (or in this case miss-detection) which should allow it to read and dump the EPC settings.

@andersonsmith
Copy link
Author

Thanks for the replies. Using --forceSCSI did indeed allow the timers to show correctly. I tried to force the standby mode with --transitionPower standby_z but only received Device is in the Active State or in an Unknown state. afterwards. I continued to every 5 seconds or so but it didn't change from this.

Regarding the info dump, here it is:

==========================================================================================
 openSeaChest_PowerControl - openSeaChest drive utilities - NVMe Enabled
 Copyright (c) 2014-2024 Seagate Technology LLC and/or its Affiliates, All Rights Reserved
 openSeaChest_PowerControl Version: 3.6.0-8_0_1 X86_64
 Build Date: Aug 28 2024
 Today: 20240903T205432 User: root
==========================================================================================

/dev/sg7 - ST2000NM0001 - Z1P20M8C - XRBA - UNKNOWN

---Low Level tDevice information---
        ---Drive Info---
                media type: HDD
                drive type: unknown
                interface type: SCSI/SAS/FC/etc
                zoned type: not zoned
                ---adapter info---
                        PCI/PCIe:
                        VendorID: 1000h
                        ProductID: 0097h
                        Revision: 0002h
                ---driver info---
                        driver name: mpt3sas
                        driver version string:
                SCSI Version: 6
                ---Passthrough Hacks---
                        Passthrough type: SAT/system/none
                                ---SCSI Hacks---
                                ---NVMe Hacks---
                                ---ATA Hacks---
        ---OS Info---
                handle name: /dev/sg7
                friendly name: sg7
                minimum memory alignment: 8
                ---Linux Unique info---
                        FD is valid
                        SG Driver Version:
                                Major: 3
                                Minor: 5
                                Revision: 36
                OS read-write recommended: false
                last recorded error: 0
                File system Info:
                        No active file systems detected

@vonericsen
Copy link
Contributor

@andersonsmith,

This bug has been very difficult to locate so far walking through the code with the information you have shared so far.
Do you see this message show up at all? SCSI interface, unknown drive type

Can you run this command line and share the output with me?
openSeaChest_PowerControl -d <handle> --transitionPower standby_z --checkPowerMode -v4 | tee verboseSCSIPower.txt

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.

@andersonsmith
Copy link
Author

Where would I find that error message?

I ran the command with and without --forceSCSI in case that matters.

verboseSCSIPower.txt
verboseSCSIPower-withforce.txt

@vonericsen
Copy link
Contributor

Thank you for the logs!
I believe I have identified the issue causing "Unknown Drive" so that --forceSCSI is not necessary.

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.
While reviewing the standards I can try adding another command into this process to see if it can detect this state: test unit ready.
It may not give as much detail, but I think I can make that work.

You can try spinning the drive down, then trying openSeaChest_PowerControl -d <handle> --testUnitReady to see if it has spun down. If it has spun down, then the sense will most likely say Logical Unit Not Ready - Initializing Command Required which essentially means it is in standby.
I'll work on adding this in as well, but if you could try this and let me know what you see that would also be helpful to confirm what the drive is doing and reporting in your case.

vonericsen added a commit to Seagate/opensea-transport that referenced this issue Sep 6, 2024
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 <[email protected]>
vonericsen added a commit to Seagate/opensea-operations that referenced this issue Sep 6, 2024
… 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 <[email protected]>
vonericsen added a commit that referenced this issue Sep 6, 2024
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 <[email protected]>
@vonericsen
Copy link
Contributor

@andersonsmith,

Can you give the attached build a try and let me know if it works for you to show standby?
If it does not, can you share the output again like you did previously?
openSeaChest_PowerControl -d <handle> --transitionPower standby --checkPowerMode -v4 | tee verbosePowerCheck.txt

linux-x86_64-portable.zip
multiple.intoto.jsonl.zip

@andersonsmith
Copy link
Author

andersonsmith commented Sep 7, 2024

Output attached. When I check with --showEPCSettings immediately after it went back to Active or unknown state but I assume that due to disk activity.

verbosePowerCheck.txt

Should an asterisk be shown with each timer in --showEPCSettings? I see it appearing and disappearing when I enable and disable idle_a but it doesn't appear when I enable standby_y or standby_z

@vonericsen
Copy link
Contributor

@andersonsmith,

Thanks for the log again!

When I check with --showEPCSettings immediately after it went back to Active or unknown state but I assume that due to disk activity.

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.
This can change between products as well.

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.
When I had this reported years ago the issue was using the sd? handle caused a spinup, but using sg did not.
My solution to this to keep customer usage easy for the handle they are familiar with was to map it myself using sysfs.
If the mapping fails, it uses whatever handle the user provides since some kernels disable /dev/sg? handles (usually only embedded devices).
This issue is not appearing in your logs since I see it using the sg handle, but it is always possible that something in the kernel has changed this behavior, although I am not aware of anything that would affect this right now.

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.

Should an asterisk be shown with each timer in --showEPCSettings? I see it appearing and disappearing when I enable and disable idle_a but it doesn't appear when I enable standby_y or standby_z

Yes, that should be changing.
I just reviewed the code and this is a bug.
It looks like when reading one page there was a mix up on which bit was used for standby y vs standby z. I also found a bug reading the mode page settings where the length of the mode page header was not being factored into the offset to check.
This only seems to affect the standby states which is why you didn't see the issue with idle a.

I'm reviewing more of the code before I push the fix, but I will share that for you to check out as well.

vonericsen added a commit to Seagate/opensea-operations that referenced this issue Sep 9, 2024
…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 <[email protected]>
vonericsen added a commit that referenced this issue Sep 9, 2024
@vonericsen
Copy link
Contributor

@andersonsmith,

Can you give these updated builds a test to see if it fixes the asterisk in the EPC settings?
I fixed the issues I mentioned in my last comment that should resolve it.

multiple.intoto.jsonl.zip
linux-x86_64-portable.zip

@andersonsmith
Copy link
Author

andersonsmith commented Sep 10, 2024

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 sdparm when referring to the bias for power management?

   /dev/sg7: SEAGATE   ST2000NM0001      XRBA
   Direct access device specific parameters: WP=0  DPOFUA=1
Power condition [po] mode page:
 PM_BG         0  [cha: n, def:  0, sav:  0]  Power management, background functions, precedence
 STANDBY_Y     1  [cha: y, def:  0, sav:  1]  Standby_y timer enable
 IDLE_C        0  [cha: n, def:  0, sav:  0]  Idle_c timer enable
 IDLE_B        1  [cha: y, def:  0, sav:  1]  Idle_b timer enable
 IDLE_A        1  [cha: y, def:  0, sav:  1]  Idle_a timer enable
 STANDBY_Z     1  [cha: y, def:  0, sav:  1]  Standby_z timer enable
 IACT          10  [cha: y, def: 10, sav: 10]  Idle_a condition timer (100 ms)
 SZCT          9000  [cha: y, def:36000, sav:9000]  Standby_z condition timer (100 ms)
 IBCT          2400  [cha: y, def:6000, sav:2400]  Idle_b condition timer (100 ms)
 ICCT          0  [cha: n, def:  0, sav:  0]  Idle_c condition timer (100 ms)
 SYCT          6000  [cha: y, def:18000, sav:6000]  Standby_y condition timer (100 ms)
 CCF_IDLE      0  [cha: n, def:  0, sav:  0]  check condition if from idle_c
 CCF_STAND     0  [cha: n, def:  0, sav:  0]  check condition if from a standby
 CCF_STOPP     0  [cha: n, def:  0, sav:  0]  check condition if from stopped

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.

@vonericsen
Copy link
Contributor

vonericsen commented Sep 10, 2024

Thanks for reporting that fixed the asterisk!

I assume you are referring to this output from sdparm when referring to the bias for power management?
Specifically thinking of the top line? I assume that it is currently set to power management rather than background.

Yes, the PM_BG line is what I'm referring to in this case.
When set to zero like in your output this is defined as vendor specific in the spec, which is used to say it's up to the firmware to decide this precedence between background tasks and power management. This is what the defined behavior of SATA drives is as well since there is no method to change this behavior on SATA.
Sometimes this also is a "backwards compatibility" setting when a field used to be unused, it means it was not defined in a previous standard or draft of a standard and in newer standards it now has meaning, so previous behavior of that field was left up to the firmware.

A firmware may also set something to vendor specific when it was incapable of changing that behavior. That may be selectable on some drive firmware, but I do not know off the top of my head.

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.

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 openSeaChest_SMART there is the option --deviceStatistics which can print out some counters for how many times a drive has entered these different power states. I cannot say for sure that it is supported on this firmware or not, but you can try that and check the counter to see if it's incrementing over time or not.

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.

@andersonsmith
Copy link
Author

andersonsmith commented Sep 10, 2024

Thanks for the suggestion. Looks to me like it's having trouble getting beyond idle_A The timer for idle_B is set to 4 min and standby_Z is set to 15 minutes for this particular drive. Will dive into the stats to see what the system is doing. This is mostly media so should spend a significant amount of the day idle. Thanks again for your work on this - this is a very handy tool.

---Power Condition Transitions---
 Accumulated Transitions to Active                            N/A              589
 Accumulated Transitions to Idle A                            N/A              4431195
 Accumulated Transitions to Idle B                            N/A              583
 Accumulated Transitions to Idle C                            N/A              0
 Accumulated Transitions to Standby Z                         N/A              6
 Accumulated Transitions to Standby Y                         N/A              0

vonericsen added a commit to Seagate/opensea-transport that referenced this issue Sep 10, 2024
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 <[email protected]>
vonericsen added a commit to Seagate/opensea-operations that referenced this issue Sep 10, 2024
… 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 <[email protected]>
vonericsen added a commit to Seagate/opensea-operations that referenced this issue Sep 10, 2024
…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 <[email protected]>
@vonericsen
Copy link
Contributor

@andersonsmith,

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 not yet started a page on power options like EPC, but I will put some of the information from here into that wiki page when I get to writing it.

@vonericsen
Copy link
Contributor

vonericsen commented Sep 26, 2024

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 😄

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants