linux-ide.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Aaron Lu <aaron.lwe@gmail.com>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Aaron Lu <aaron.lu@intel.com>,
	bladud@gmail.com, Joe Sapp <nixphoeni+kernel@gmail.com>,
	Alberto Mattea <support.intranet@libero.it>,
	Peter Dons Tychsen <donpedro@tdcadsl.dk>,
	Robert Hancock <hancockrwd@gmail.com>,
	"linux-ide@vger.kernel.org" <linux-ide@vger.kernel.org>,
	Tejun Heo <tj@kernel.org>, Jeff Garzik <jgarzik@pobox.com>,
	linux-scsi <linux-scsi@vger.kernel.org>,
	Alan Stern <stern@rowland.harvard.edu>
Subject: Re: STANDBY IMMEDIATE failed on NVIDIA MCP5x controllers when system suspend
Date: Mon, 11 Mar 2013 21:51:50 +0800	[thread overview]
Message-ID: <513DE176.7050405@gmail.com> (raw)
In-Reply-To: <1362991742.2395.9.camel@dabdike.int.hansenpartnership.com>

On 2013-03-11 16:49, James Bottomley wrote:
> On Mon, 2013-03-11 at 11:42 +0800, Aaron Lu wrote:
>> Hi all,
>>
>> I've seen some reports on STANDBY IMMEDIATE failed on NVIDIA MCP5x
>> controllers when system goes to suspend(this command is sent by scsi sd
>> driver on system suspend as a SCSI STOP command, which is translated to
>> STANDBY IMMEDIATE ATA command). I've no idea of why this happened, so
>> I wrote this email in hope of getting some new idea.
>>
>> The related bug report:
>> https://bugzilla.kernel.org/show_bug.cgi?id=48951
>>
>> And google search showed that Peter reported a similar problem here:
>> http://marc.info/?l=linux-ide&m=133534061316338&w=2
>>
>> And bladud has found that, disable asyn suspend for the scsi target
>> device can work around this problem.
>>
>> Please feel free to suggest what can possibly be the cause, thanks.
>
> You really need to discriminate better between conditions we should and
> shouldn't care about for suspend.  so in sd_suspend, we definitely care
> if we can't flush the cache of a write back device because the power off
> could lose data.  We don't really care if the disk says I can't stop, so
> this is probably the correct fix.

Yes, this will make suspend succeed, but the problem is still there -
the drive does not respond to this command, while it will if async
suspend for the target device is disabled. I don't think scsi code has
any fault here, it feels more like a chip bug to me.

And if we solve it this way, affected user may complain about long
delay when suspending or uncomfortable with the error messages in dmesg,
since that command would eventually timeout. So I hope we can nderstand
what is going wrong here and perhaps do something to avoid it.

Thanks,
Aaron

>
> ---
> diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
> index 7992635..384b621d 100644
> --- a/drivers/scsi/sd.c
> +++ b/drivers/scsi/sd.c
> @@ -3079,7 +3079,11 @@ static int sd_suspend(struct device *dev)
>
>   	if (sdkp->device->manage_start_stop) {
>   		sd_printk(KERN_NOTICE, sdkp, "Stopping disk\n");
> -		ret = sd_start_stop_device(sdkp, 0);
> +		/*
> +		 * this is informational for the disk we're going to power it
> +		 * off anyway, so don't bother about the return status
> +		 */
> +		sd_start_stop_device(sdkp, 0);
>   	}
>
>   done:
>
>

  reply	other threads:[~2013-03-11 13:51 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-11  3:42 STANDBY IMMEDIATE failed on NVIDIA MCP5x controllers when system suspend Aaron Lu
2013-03-11  8:49 ` James Bottomley
2013-03-11 13:51   ` Aaron Lu [this message]
2013-03-11 14:34     ` James Bottomley
2013-03-11 15:00       ` Alan Stern
2013-03-12  2:53         ` Aaron Lu
2013-03-12 12:10           ` James Bottomley
2013-03-12 13:46             ` Aaron Lu
2013-03-12 15:08           ` Alan Stern
2013-03-11 14:35   ` Robert Hancock
2013-03-11 14:51     ` James Bottomley
2013-03-11 19:30       ` Robert Hancock
2013-03-12 16:34         ` Mark Lord
2013-03-11 20:01 ` Peter Dons Tychsen
2013-03-12  2:34   ` Aaron Lu
2013-03-12 23:21     ` Peter Dons Tychsen
2013-03-13  2:10       ` Robert Hancock
2013-03-13  2:36         ` Aaron Lu
2013-03-13  4:50           ` Simeon Bird
2013-03-13  5:07             ` Aaron Lu
2013-03-13  5:16               ` Simeon Bird
2013-03-13  5:41                 ` Aaron Lu

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=513DE176.7050405@gmail.com \
    --to=aaron.lwe@gmail.com \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=aaron.lu@intel.com \
    --cc=bladud@gmail.com \
    --cc=donpedro@tdcadsl.dk \
    --cc=hancockrwd@gmail.com \
    --cc=jgarzik@pobox.com \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=nixphoeni+kernel@gmail.com \
    --cc=stern@rowland.harvard.edu \
    --cc=support.intranet@libero.it \
    --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).