Elias Oltmanns wrote:
> 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.
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
--
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
