From: Stephan Diestelhorst <stephan.diestelhorst@gmail.com>
To: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Tejun Heo <tj@kernel.org>,
linux-kernel@vger.kernel.org, linux-ide@vger.kernel.org,
linux-pm@lists.osdl.org, stephan.diestelhorst@gmail.com,
stephan.diestelhorst@amd.com
Subject: Re: HDD not suspending properly / dead on resume
Date: Sat, 10 Jul 2010 08:50:34 +0200 [thread overview]
Message-ID: <201007100850.36889.stephan.diestelhorst@gmail.com> (raw)
In-Reply-To: <201007100206.13401.rjw@sisk.pl>
Rafael J. Wysocki wrote:
> On Saturday, July 10, 2010, Stephan Diestelhorst wrote:
> > Rafael J. Wysocki wrote:
> > > On Friday, July 09, 2010, Stephan Diestelhorst wrote:
> > > > I wrote:
> > > > > I have an issue with suspend to RAM and I/O load on a disk. Symptoms
> > > > > are that the disk does not respond to requests when woken up, producing
> > > > > only I/O errors on all tested kernels (newest 2.6.35-rc4 (Ubuntu
> > > > > mainline PPA build)):
> > > > >
> > > > <snip>
> > > >
> > > > > This can be triggered most reliably with multiple "direct" writes to
> > > > > disk, I create the load with the attached script. If the issue is
> > > > > triggered, suspend (through pm-suspend) takes very long.
> > > >
> > > > > IMHO the interesting log output during suspend is:
> > > > > [ 1674.700125] ata1.00: qc timeout (cmd 0xec)
>
> I have a box where this problem is kind of reproducible, but it happens _very_
> rarely. Also I can't reproduce it on demand running suspend-resume in a tight
> loop. Are you able to reproduce it more regurarly?
For me it is much more reproducible. If I run multiple direct writing
dd-s to the disk in question I trigger it rather reliably (~75% or
higher). See the attached script from an earlier email.
Maybe that helps triggering your case more reliabl, too?
> Also, what kind of disk do you use?
It is a Samsung HM321HI in a Samsung Eikee R525 notebook, please also
see my smartctl -a log, attached earlier.
Interesting, I have a similar symptom on one of my home servers,
which has a *Samsung* SpinPoint F1 and it went away with different
disks. So maybe these disks are either faulty themselves or they
trigger the issue more often?
I also have a LVM on top of LUKS on the disk. So the I/O will also
add some computational overhead for encryption.
Stephan
next prev parent reply other threads:[~2010-07-10 6:50 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-09 15:50 HDD not suspending properly / dead on resume Stephan Diestelhorst
2010-07-09 21:47 ` Stephan Diestelhorst
2010-07-09 21:53 ` Rafael J. Wysocki
2010-07-09 23:04 ` Stephan Diestelhorst
2010-07-10 0:06 ` Rafael J. Wysocki
2010-07-10 6:50 ` Stephan Diestelhorst [this message]
2010-07-10 10:03 ` Tejun Heo
2010-07-10 13:45 ` Rafael J. Wysocki
2010-07-28 21:50 ` [PATCH] SATA / AHCI: Do not play with the link PM during suspend to RAM (was: Re: HDD not suspending properly / dead on resume) Rafael J. Wysocki
2010-07-30 14:18 ` [PATCH] SATA / AHCI: Do not play with the link PM during suspend to RAM Tejun Heo
2010-08-05 16:08 ` Tejun Heo
2010-08-05 19:58 ` Rafael J. Wysocki
2010-08-06 6:30 ` Stephan Diestelhorst
2010-08-06 7:06 ` Tejun Heo
2010-08-06 9:04 ` Stephan Diestelhorst
2010-08-17 7:51 ` Stephan Diestelhorst
2010-08-17 8:08 ` Tejun Heo
2010-08-17 9:32 ` Stephan Diestelhorst
2010-08-17 10:15 ` Tejun Heo
2010-08-17 10:29 ` Stephan Diestelhorst
2010-08-17 10:51 ` Stephan Diestelhorst
2010-08-17 15:04 ` Tejun Heo
2010-08-17 21:28 ` Stephan Diestelhorst
2010-08-18 6:12 ` Tejun Heo
2010-08-19 16:23 ` Stephan Diestelhorst
2010-08-23 12:03 ` Tejun Heo
2010-08-23 18:58 ` Rafael J. Wysocki
2010-08-24 7:37 ` Tejun Heo
2010-08-24 20:39 ` Rafael J. Wysocki
2010-08-26 23:09 ` Rafael J. Wysocki
2010-08-26 23:46 ` Rafael J. Wysocki
2010-09-02 9:06 ` Tejun Heo
2010-09-02 10:02 ` [PATCH] libata: skip EH autopsy and recovery during suspend Tejun Heo
2010-09-02 14:33 ` Stephan Diestelhorst
2010-09-02 20:11 ` Rafael J. Wysocki
2010-09-02 20:52 ` Stephan Diestelhorst
2010-09-07 11:54 ` Stephan Diestelhorst
2010-09-02 20:16 ` Rafael J. Wysocki
2010-09-02 20:25 ` Tejun Heo
2010-09-02 20:28 ` Rafael J. Wysocki
2010-09-02 20:33 ` Tejun Heo
2010-09-02 21:01 ` [linux-pm] " Alan Stern
2010-09-02 21:09 ` Rafael J. Wysocki
2010-09-03 8:55 ` [linux-pm] " Tejun Heo
2010-09-03 14:16 ` Alan Stern
2010-09-07 12:05 ` [PATCH #upstream-fixes] " Tejun Heo
2010-08-24 16:07 ` [PATCH] SATA / AHCI: Do not play with the link PM during suspend to RAM Stephan Diestelhorst
2010-08-24 16:11 ` Stephan Diestelhorst
2010-08-26 16:15 ` Stephan Diestelhorst
2010-08-26 18:24 ` Rafael J. Wysocki
2010-08-27 23:35 ` Rafael J. Wysocki
2010-09-02 14:31 ` Stephan Diestelhorst
2010-08-17 11:19 ` Rafael J. Wysocki
2010-08-17 11:29 ` Tejun Heo
2010-08-17 12:10 ` Stephan Diestelhorst
2010-08-17 12:09 ` Tejun Heo
2010-08-02 20:48 ` [PATCH] SATA / AHCI: Do not play with the link PM during suspend to RAM (was: Re: HDD not suspending properly / dead on resume) Stephan Diestelhorst
2010-08-02 21:38 ` Rafael J. Wysocki
2010-08-03 8:36 ` Stephan Diestelhorst
2010-08-03 21:13 ` Rafael J. Wysocki
2010-07-10 13:08 ` HDD not suspending properly / dead on resume Rafael J. Wysocki
2010-07-12 15:35 ` Maciej Rutecki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201007100850.36889.stephan.diestelhorst@gmail.com \
--to=stephan.diestelhorst@gmail.com \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@lists.osdl.org \
--cc=rjw@sisk.pl \
--cc=stephan.diestelhorst@amd.com \
--cc=tj@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).