Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Ubuntu Kernel Team (http://www.linux-archive.org/ubuntu-kernel-team/)
-   -   Slow Resume with SSD (http://www.linux-archive.org/ubuntu-kernel-team/707317-slow-resume-ssd.html)

"Peter M. Petrakis" 09-25-2012 07:18 PM

Slow Resume with SSD
 
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@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

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team

Carlos Moffat 09-25-2012 07:32 PM

Slow Resume with SSD
 
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.



Ok, good to know.


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



Yes!


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.





I'm using the up-to-date firmware for the drive, as well as latest BIOS.

As for your suggestiong od reducing the link speed:

Confirm speed drop:

[ 32.911480] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 320)

but got the same result:

[ 32.929393] PM: resume of devices complete after 10368.776 msecs




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


Ok. I barely use Windows, but I'll give a try and report back.






Any ideas?



File an LP bug against the kernel and if you're up to upstream testing,
jump on linux-ide@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,



Will do.

Thanks, Peter.

Carlos


Peter

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



--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team

Carlos Moffat 09-25-2012 08:03 PM

Slow Resume with SSD
 
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@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



--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team

"Peter M. Petrakis" 09-25-2012 08:59 PM

Slow Resume with SSD
 
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@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



--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team


All times are GMT. The time now is 01:01 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.