Slow Resume with SSD

Carlos Moffat carlos at eldiabloenlosdetalles.net
Tue Sep 25 20:03:09 UTC 2012



On 09/25/2012 12:18 PM, Peter M. Petrakis wrote:
>
>
> 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.
>

So it takes around 4 sec to resume on Windows 7. Ubuntu 3.5.4 is around 
12-14 sec.

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




More information about the kernel-team mailing list