linux-ide.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tejun Heo <tj@kernel.org>
To: Elias Oltmanns <eo@nebensachen.de>
Cc: Mark Lord <liml@rtr.ca>, Evgeni Golov <sargentd@die-welt.net>,
	linux-ide@vger.kernel.org, Alan Cox <alan@lxorguk.ukuu.org.uk>
Subject: Re: Odd behaviour of device in response to idleimmediate with unload
Date: Fri, 07 Nov 2008 13:08:29 +0900	[thread overview]
Message-ID: <4913BF3D.3090704@kernel.org> (raw)
In-Reply-To: <87k5bhxerq.fsf@denkblock.local>

Elias Oltmanns wrote:
> Tejun Heo <tj@kernel.org> wrote:
>> Elias Oltmanns wrote:
> [...]
>>> As a wild guess, I'm wondering whether ata_eh_revalidate_and_attach()
>>> has anything to do with it. Unless you have a better suggestion, perhaps
>>> the following debug patch would give some useful information.
>> I don't have much idea at this point.  To the drive, it shouldn't look
>> any different.  Ah... it's ata_piix, right?  ata_piix doesn't have PHY
>> event IRQ, so it could be that the command issued by hdparm did trigger
>> PHY event but didn't get noticed by EH while the condition triggered by
>> IDLE IMMEDIATE did.  One way to find out would be adding SCR print outs
>> on command completion.
> 
> Actually, event notification is turned off during error recovery for
> ahci as well.

Yeap, but SError is checked and cleared after event notification is
turned back on, so events shouldn't leak.

> Additionally, we have the following in the interrupt
> handler of ahci.c:
> 
> 	/* If we are getting PhyRdy, this is
>  	 * just a power state change, we should
>  	 * clear out this, plus the PhyRdy/Comm
>  	 * Wake bits from Serror
>  	 */
> 	if ((hpriv->flags & AHCI_HFLAG_NO_HOTPLUG) &&
> 		(status & PORT_IRQ_PHYRDY)) {
> 		status &= ~PORT_IRQ_PHYRDY;
> 		ahci_scr_write(&ap->link, SCR_ERROR, ((1 << 16) | (1 << 18)));
> 	}
> 
> This suggests to me that hdparm --idle-unload does indeed trigger a phy
> event, but the interrupt handler clears SError. Issuing the unload
> command in EH, on the other hand, does not result in a phy event because
> event notification is disabled. That way, phyrdy and commwake don't get
> cleared in SError in will indicate a hotplug event next time SError is
> checked. Does that make sense? If so, what's to be done about it?

Hmmm... if ALPM is enabled, it could explain all.  Enabling ALPM does
inhibit event notifications but it doesn't prevent autopsy from
interpreting SError as if ALPM is not enabled.

Evgeni, is ALPM enabled?

Thanks.

-- 
tejun

  reply	other threads:[~2008-11-07  4:08 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-04 10:31 Odd behaviour of device in response to idleimmediate with unload Elias Oltmanns
2008-11-04 10:40 ` Tejun Heo
2008-11-04 12:32   ` Evgeni Golov
2008-11-04 17:06     ` Mark Lord
2008-11-04 17:18       ` Mark Lord
2008-11-04 17:47         ` Mark Lord
2008-11-04 18:13           ` Mark Lord
2008-11-04 18:54             ` Evgeni Golov
2008-11-04 19:39               ` Mark Lord
2008-11-05  9:32                 ` Tejun Heo
2008-11-05 13:47                   ` Elias Oltmanns
2008-11-05 14:08                     ` Tejun Heo
2008-11-05 18:55                       ` Elias Oltmanns
2008-11-06 11:23                         ` Evgeni Golov
2008-11-06 12:12                           ` Elias Oltmanns
2008-11-05 19:34                       ` Evgeni Golov
2008-11-06 11:41                       ` Elias Oltmanns
2008-11-07  4:08                         ` Tejun Heo [this message]
2008-11-07  7:48                           ` Evgeni Golov
2008-11-10  9:00                             ` Tejun Heo
2008-11-10 10:26                               ` Evgeni Golov
2008-11-10 11:35                                 ` Elias Oltmanns
2008-11-13 11:33                                   ` Evgeni Golov
2008-11-13 12:29                                     ` Elias Oltmanns
2008-11-16  9:39                                     ` Tejun Heo
2008-11-17  7:15                                       ` Evgeni Golov
2008-11-17  7:19                                         ` Tejun Heo
2008-11-17  7:48                                           ` Evgeni Golov
2008-11-18  1:22                                             ` Tejun Heo
2008-11-18  7:37                                               ` Evgeni Golov
2008-11-21  6:41                                                 ` Tejun Heo
2008-11-21 19:40                                                   ` Evgeni Golov
2008-11-22  8:22                                                     ` Tejun Heo
2008-11-22  9:51                                                       ` Evgeni Golov
2008-11-22  9:58                                                       ` Evgeni Golov
2008-11-23 18:09                                                       ` Elias Oltmanns
2008-11-24  4:20                                                         ` Tejun Heo

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=4913BF3D.3090704@kernel.org \
    --to=tj@kernel.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=eo@nebensachen.de \
    --cc=liml@rtr.ca \
    --cc=linux-ide@vger.kernel.org \
    --cc=sargentd@die-welt.net \
    /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).