Re: Odd behaviour of device in response to idleimmediate with unload

[Elias Oltmanns <eo@nebensachen.de>]

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

Regards,

Elias