Marvell PCIe SSD controller 0x9183 suspend/resume problem
https://bugzilla.kernel.org/show_bug.cgi?id=62351
Patrik Jakobsson <[email protected]> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected]
Signature · 2 lines
You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=62351
Tejun Heo <[email protected]> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected]
--- Comment #2 from Tejun Heo <[email protected]> ---
Hello, Patrik.
Can you please do "echo min_power > /sys/class/scsi_host/host0/link_power_management_policy" before suspend and see whether anything changes?
Thanks.
Signature · 2 lines
You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=62351
--- Comment #3 from Patrik Jakobsson <[email protected]> --- Hi Tejun
Success!
Setting min_power before suspend makes the error go away. Sadly pm-utils sets max_performance so it needs to be configured and for some reason it doesn't take my /etc/pm/config.d/sata_alpm into account. I ended up copying /usr/lib/pm-utils/power.d/sata_alpm to /etc/pm/power.d and forcing it to min_power. Also added a link to it in /etc/pm/sleep.d/ so it sets min_power before suspend.
Strangely the SATA device randomly appears on /sys/class/scsi_host/host0 and ../host1 but I just set them both (the other is USB) and that works fine.
Thanks
Patrik
Signature · 2 lines
You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=62351
--- Comment #4 from Tejun Heo <[email protected]> ---
So, when the machine boots up libata doesn't touch the LPM setting and just considers it "max_performance", which may or may not be true. I think it'd work the same if you just set the lpm knob to max_performance explicitly. The problem is that your BIOS is most likely configuring DIPM on both the device and host sides during boot; however, after coming back from suspend, the device side seems to be configured but the host side isn't, so the device's LPM operations register as link events to the controller leading to the spurious failures.
Maybe we should set max_performance mode explicitly during boot requiring the user to explicitly set min_power mode if [s]he wants to but then we might cause power regression on some setups.
Anyways, can you please verify echoing max_performance also makes the issue go away?
Signature · 2 lines
You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=62351
--- Comment #5 from Patrik Jakobsson <[email protected]> --- Here are all the test cases:
After boot: LPM policy reports max_performance and min_power and max_performance can be switched back and forth without any errors.
Before suspend: If I don't touch LPM policy after boot (still reporting max_performance) I can successfully suspend and LPM policy still reports max_performance (though probably incorrect) after resume.
Before suspend: If I explicity set max_performance after boot and go into suspend it fails. If I set min_power back in this state, the errors stop.
Before suspend: If I explicity set min_power after boot and go into suspend it succeeds.
So I must either never touch the LPM policy or set it to min_power to not get the errors on resume. min_power seems to be what the hardware is set to but doesn't get reported correctly (as you say) until I've actually set it to something.
Signature · 2 lines
You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=62351
--- Comment #6 from Tejun Heo <[email protected]> ---
So, if you set "max_performance" explicitly, it works fine before suspending but after resuming it causes problems? What happens if you set "max_performance" explicitly instead of "min_power" after resume while the errors are happening? Does that resolve the issue too?
Thanks.
Signature · 2 lines
You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=62351
--- Comment #7 from Patrik Jakobsson <[email protected]> ---
Quoted 1 line
So, if you set "
max_performance" explicitly, it works fine before suspending but after resuming it causes problems?
Yes, the only time I can set max_performance without getting errors is before first suspend.
Quoted 1 line
What happens if you set "
max_performance" explicitly instead of "min_power" after resume while the errors are happening? Does that resolve the issue too?
Setting max_performance explicitly after resume doesn't help. And if I first set min_power after resume to stop the errors and then try max_performance again, it will start spitting out errors again.
Signature · 2 lines
You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=62351
Lionel Landwerlin <[email protected]> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected]
--- Comment #8 from Lionel Landwerlin <[email protected]> --- *** Bug 67721 has been marked as a duplicate of this bug. ***
Signature · 2 lines
You are receiving this mail because: You are on the CC list for the bug.