Hello,
(Can you please flow the text a bit below 80 column when you reply?)
On Wed, Jul 06, 2016 at 02:51:47AM +0000, Pang Raymond wrote:
> Why does the phenomenon appear?
> Two factors cause this problem.
> 1. In MSIx's irq handler
> (ahci_multi_irqs_intr_hard()), we do not clear
> GHC.IS register which presents which ports need
> interrupt service. static irqreturn_t
> ahci_multi_irqs_intr_hard(int irq, void
> *dev_instance)
> {
> // omitting unconcerned codes here
> // ...
> // here we just clear PxIS register, not clear GHC.IS
> status = readl(port_mmio + PORT_IRQ_STAT);
> writel(status, port_mmio + PORT_IRQ_STAT);
> // ...
> }
> 2. In PCI subsystem, after Disable MSIx, INTx is
> enabled automatically.
> void pci_msix_shutdown(struct pci_dev *dev)
> {
> // omitting unconcerned codes here
> // ...
> // after Disable MSIx, enable INTx imediately
> pci_msix_clear_and_set_ctrl(dev, PCI_MSIX_FLAGS_ENABLE, 0);
> pci_intx_for_msi(dev, 1);
> dev->msix_enabled = 0;
> pcibios_alloc_irq(dev);
> }
>
> When Kernel enables INTx(I mean clearing PCI configure space
> Rx04.bit10), controller will find GHC.IS is not Zero (because driver
> haven't cleared GHC.IS after servicing MSIx interrupt), so it
> believes some SATA ports need interrupt servicing and asserts INTx
> interrupt.
Looks like you debugged the problem. Care to write up and test a
patch?
Thanks a lot!
--
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
