Tejun Heo <tj@xxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
