On Fri, Jan 24, 2003 at 02:31:35PM -0500, Jeff Garzik wrote:
> On Fri, Jan 24, 2003 at 09:27:48PM +0300, Ivan Kokshaysky wrote:
> > --- 2.5.59/drivers/net/tg3.c Fri Jan 17 05:22:16 2003
> > +++ linux/drivers/net/tg3.c Fri Jan 24 19:28:44 2003
> > @@ -3096,7 +3096,12 @@ static void tg3_chip_reset(struct tg3 *t
> > val |= PCISTATE_RETRY_SAME_DMA;
> > pci_write_config_dword(tp->pdev, TG3PCI_PCISTATE, val);
> >
> > - pci_restore_state(tp->pdev, tp->pci_cfg_state);
> > + pci_restore_extended_state(tp->pdev, tp->pci_cfg_state);
> > +
> > + /* Make sure MSGINT_MODE is set if MSI is configured. */
> > + pci_read_config_dword(tp->pdev, TG3PCI_MSI_CAP_ID, &val);
> > + if ((val >> 16) & PCI_MSI_FLAGS_ENABLE)
> > + tw32(MSGINT_MODE, MSGINT_MODE_ENABLE);
> >
> > /* Make sure PCI-X relaxed ordering bit is clear. */
> > pci_read_config_dword(tp->pdev, TG3PCI_X_CAPS, &val);
>
> hmmmm. We don't use MSI in the driver anymore, unless I am missing
> something.
>
> So, the above patch is probably the wrong thing to do. I'll need to
> check to be sure, but I think that h/w reset clears MSGINT_MODE_ENABLE,
> so we wouldn't want to be randomly enabling it when it is purposefully
> disabled.
>
> DaveM/Jeff, corrections?
The problem is that if the chip is configured for MSI (through config
space) and the platform's irq mapping code therefore filled in
pci_dev->irq with an appropriate vector for the MSI interrupt the chip
is assigned instead of the LSI interrupt it may also be assigned, then
unless MSGINT_MODE matches PCI_MSI_FLAGS_ENABLE, the driver will grab
wrong interrupt.
/jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Jan 31 2003 - 22:00:12 EST