[Bug 62351] Marvell PCIe SSD controller 0x9183 suspend/resume problem

[Bug 62351] Marvell PCIe SSD controller 0x9183 suspend/resume problem

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=62351

Patrik Jakobsson <patrik.r.jakobsson@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |linux-ide@vger.kernel.org

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 62351] Marvell PCIe SSD controller 0x9183 suspend/resume problem

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=62351

Tejun Heo <tj@kernel.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tj@kernel.org

--- Comment #2 from Tejun Heo <tj@kernel.org> ---
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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 62351] Marvell PCIe SSD controller 0x9183 suspend/resume problem

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=62351

--- Comment #3 from Patrik Jakobsson <patrik.r.jakobsson@gmail.com> ---
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

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 62351] Marvell PCIe SSD controller 0x9183 suspend/resume problem

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=62351

--- Comment #4 from Tejun Heo <tj@kernel.org> ---
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?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 62351] Marvell PCIe SSD controller 0x9183 suspend/resume problem

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=62351

--- Comment #5 from Patrik Jakobsson <patrik.r.jakobsson@gmail.com> ---
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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 62351] Marvell PCIe SSD controller 0x9183 suspend/resume problem

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=62351

--- Comment #6 from Tejun Heo <tj@kernel.org> ---
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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 62351] Marvell PCIe SSD controller 0x9183 suspend/resume problem

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=62351

--- Comment #7 from Patrik Jakobsson <patrik.r.jakobsson@gmail.com> ---
> 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.

> 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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 62351] Marvell PCIe SSD controller 0x9183 suspend/resume problem

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=62351

Lionel Landwerlin <llandwerlin@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |llandwerlin@gmail.com

--- Comment #8 from Lionel Landwerlin <llandwerlin@gmail.com> ---
*** Bug 67721 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are on the CC list for the bug.