Slow Resume with SSD

[Peter M. Petrakis]

On 09/25/2012 02:24 PM, Carlos Moffat wrote:
> Hi,
>
> (please let me know if this is the wrong list to ask this)
>
> I have a Crucial M4 512 GB SSD installed on my Thinkpad X220 (Ubuntu
> Precise). Overall this runs very nicely, but it takes 10+ seconds to
> resume from suspend, apparently because some issue with the hardrive.
> The only message I see while resuming is "COMRESET failed
> (errno=-16)".

That means hard reset failed, (sok it can retry) which unfortunately
is a necessary tool to unjam disks, so I'm not surprised that
completely disabling it broke resume for you, it could have
broken boot as well.

I'm assuming that your drive is in good health and you've verified
that smart short and extended tests are returning good results.

In absence of any defects this becomes a timing issue as all we have to
work with at this level is "chirps" which when done in the right
quantity, in the right time frame, represent a valid signal.

I would try reducing the link speed to 3G and then retest. You can
do this via libata.force, http://tinyurl.com/brorgo4 [kernel-parameters.txt].
Verify that the speed has dropped via dmesg.

So adding this to you kernel params [1]: libata.force=3.0G

Should do it from the grub prompt. If that doesn't work it gets
invasive quick as it could easily be the system firmware that
drives the SATA controller being too aggressive with link speed
negotiation or the libata driver has dropped the ball somewhere.

>
> [52483.228615] ata1: link is slow to respond, please be patient
> (ready=0) [52487.870616] ata1: COMRESET failed (errno=-16)
> [52488.190222] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl
> 300) [52488.190752] ata1.00: ACPI cmd ef/02:00:00:00:00:a0 (SET
> FEATURES) succeeded [52488.190754] ata1.00: ACPI cmd
> f5/00:00:00:00:00:a0 (SECURITY FREEZE LOCK) filtered out
> [52488.190755] ata1.00: ACPI cmd ef/10:03:00:00:00:a0 (SET FEATURES)
> filtered out [52488.191849] ata1.00: ACPI cmd ef/02:00:00:00:00:a0
> (SET FEATURES) succeeded [52488.191855] ata1.00: ACPI cmd
> f5/00:00:00:00:00:a0 (SECURITY FREEZE LOCK) filtered out
> [52488.191860] ata1.00: ACPI cmd ef/10:03:00:00:00:a0 (SET FEATURES)
> filtered out [52488.192406] ata1.00: configured for UDMA/100
> [52488.206298] sd 0:0:0:0: [sda] Starting disk [52488.207334]
> Extended CMOS year: 2000 [52488.208335] PM: resume of devices
> complete after 10376.896 msecs [52488.208552] PM: resume devices took
> 10.376 seconds
>
> The only relevant post I've found was in the crucial support site:
>
> http://forums.crucial.com/t5/Solid-State-Drives-SSD/SOLVED-M4-CT512M4SSD1-7mm-512Gb-SSD-too-slow-when-laptop-wakes/td-p/102666
>
>  which suggested adding libata.force=nohrst as a boot option to get
> rid of the problem.
>

Updating your drive firmware is a good option. Updating your system
bios is a last resort, as it could disturb your ACPI runtime and affect
things like overall suspend/resume. I'd take a slow resume, over the potential
for no resume any day of the week :). It's difficult if not impossible to
go backwards for firmware updates.

  
> I tried that, but the laptop wouldn't suspend.

So when you ran Windows on this, how fast did it resume? If it was significantly
faster than Linux that would point to a driver problem more than a firmware problem.

>
> Any ideas?
>

File an LP bug against the kernel and if you're up to upstream testing,
jump on linux-ide at vger.kernel.org and present your issue there. You
may also wish to consider simply waiting it out and see if the next major
kernel release addresses your issue. Clearly this is complex problem and
the moment you start updating firmware on either side of the bus the
risk goes up; I can't make that call for you.

> Thanks, Carlos
>

Take care,

Peter

1.  https://wiki.ubuntu.com/Kernel/KernelBootParameters