Slow Resume with SSD

[Peter M. Petrakis]

On 09/25/2012 04:03 PM, Carlos Moffat wrote:
>
>
> 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.

Good, you can leave firmware alone for the moment. Please file a bug by following.

https://wiki.ubuntu.com/Kernel/Bugs

$ ubuntu-bug linux

and get all the details in there. This should get all the requisite logs. Thanks.

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