From: Robert Hancock <hancockrwd@gmail.com>
To: donpedro@tdcadsl.dk
Cc: linux-ide@vger.kernel.org
Subject: Re: Regressions in sata_nv regarding STANDYBY IMMEDIATE.
Date: Sat, 28 Apr 2012 00:30:46 -0600 [thread overview]
Message-ID: <4F9B8E96.1010802@gmail.com> (raw)
In-Reply-To: <1335337953.2409.17.camel@donpedro>
On 04/25/2012 01:12 AM, Peter Dons Tychsen wrote:
> Hello,
>
> Recent kernels broke suspend/hibernate completely on one of my setups
> after updating to more recent kernels (3.3). It used to work perfectly
> and the machine was hardly ever powered completely off (standby).
> (older M2N-E ASUS motherboard with nvidia MC55 controller).
>
> The symptoms where that the system would hang entering hibernate. The
> only complaint from the system was that command STANDBY_IMMEDIATE had
> failed.
>
> At first i assumed that the disk (an older WD Green disk) was dying, and
> replaced the disk with a cheap Seagate disk. However, this turned out
> not to be the case.
>
> Looking through the ATA code i found that STANDBY had been replaced with
> STANDBY_IMMEDIATE as it was supposed to be more compliant. Replacing it
> with the old STANDBY made the standby procedure work again.
I'm not aware of this being changed recently. If it's this commit you're
referring to, it was back in 2007:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=78981a7c6c34bddbb90da72cf6ce10953e84aad8
What was the last kernel that was known to work OK?
>
> Now the question is: The STANDBY and STANDBY_IMMEDIATE commands are for
> the disk. Why does it specifically break for disks on MCP55 and not on
> other chipsets? Does it make sense?
Not really, but these NVIDIA SATA controllers (especially the pre-AHCI
ones like this) are finicky beasts.
>
> FWIW both disks seem to suspend fine on the same controller using an
> other O/S.
>
> Later i also discovered that the new disk actually made things worse.
> Using the hack suspend worked again for the old disk. The new disk could
> now suspend but would mostly get stuck getting out of suspend as it
> would seem that the system caused it to stop responding all together
> requiring a hard reboot.
>
> Any ideas?
>
> Thanks,
>
> /pedro
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ide" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
next prev parent reply other threads:[~2012-04-28 6:30 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-25 7:12 Regressions in sata_nv regarding STANDYBY IMMEDIATE Peter Dons Tychsen
2012-04-28 6:30 ` Robert Hancock [this message]
2012-04-30 18:50 ` Peter Dons Tychsen
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=4F9B8E96.1010802@gmail.com \
--to=hancockrwd@gmail.com \
--cc=donpedro@tdcadsl.dk \
--cc=linux-ide@vger.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.