SATA device is not going to DEVSLP
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
HWE Next |
Fix Released
|
Undecided
|
Unassigned | ||
OEM Priority Project |
Fix Released
|
Critical
|
Unassigned | ||
linux (Ubuntu) |
Invalid
|
Undecided
|
Unassigned | ||
Bionic |
Fix Released
|
Undecided
|
Unassigned | ||
Cosmic |
Fix Released
|
Undecided
|
Unassigned | ||
linux-oem (Ubuntu) |
Fix Released
|
Undecided
|
AceLan Kao | ||
Bionic |
Fix Released
|
Undecided
|
Unassigned | ||
Cosmic |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
[Impact]
Any of the platforms we’ve been seeing SATA problems not going to deepest state leads to other devices not getting there during long idle or s2idle. And it also prevents the system from entering deeper PC state other than PC3.
[Fix]
Suggested from Intel and Dell to contains the following 4 commits,
and all of 4 commits are in v4.19-rc1
https:/
https:/
https:/
https:/
[Test]
Verified the power consumption on some new platforms, it improves the SATA HDD power consumption around 0.5w during long idle.
[Regression Potential]
Low, the DEVSLP function is already validated when shipped with SLP_S0
support.
description: | updated |
tags: | added: originate-from-1779984 somerville |
Changed in oem-priority: | |
importance: | Undecided → Critical |
status: | New → Triaged |
description: | updated |
description: | updated |
Changed in hwe-next: | |
status: | New → In Progress |
Changed in hwe-next: | |
status: | In Progress → Triaged |
Changed in linux-oem (Ubuntu): | |
status: | In Progress → Triaged |
description: | updated |
description: | updated |
Changed in linux-oem (Ubuntu): | |
status: | Triaged → Fix Committed |
tags: |
added: verification-done-bionic removed: verification-needed-bionic |
Changed in linux (Ubuntu Bionic): | |
status: | New → In Progress |
Changed in linux (Ubuntu Cosmic): | |
status: | New → Fix Committed |
Changed in linux-oem (Ubuntu Bionic): | |
status: | New → Fix Committed |
Changed in linux-oem (Ubuntu Cosmic): | |
status: | New → Invalid |
Changed in linux (Ubuntu Cosmic): | |
status: | Fix Committed → In Progress |
Changed in linux-oem (Ubuntu Cosmic): | |
status: | Invalid → Fix Released |
status: | Invalid → Fix Released |
Changed in linux-oem (Ubuntu): | |
status: | Fix Committed → Fix Released |
Changed in linux (Ubuntu): | |
status: | Incomplete → Invalid |
Changed in linux (Ubuntu Bionic): | |
status: | In Progress → Fix Committed |
Changed in linux (Ubuntu Cosmic): | |
status: | In Progress → Fix Committed |
Changed in hwe-next: | |
status: | Triaged → Fix Released |
Changed in oem-priority: | |
status: | Triaged → Fix Released |
The first 2 I have no concerns, but would like to see a tested-by submitted back to that patch to encourage it to land upstream.
The third patch, there has been a second submission (and will likely be a 3rd based on feedback). /patchwork. kernel. org/patch/ 10522375/
https:/
Conceptually I have no concern with the 3rd patch but just please track to make sure the right policy does get adopted from it.