Messages in this thread | | | Date | Sun, 06 Jun 2004 14:21:56 -0400 | From | Jeff Garzik <> | Subject | Re: 2.6.7-rc1 breaks forcedeth |
| |
Linus Torvalds wrote: > The thing is, the driver seems to not actually even register the irq > handler until the device is opened, which seems a bit bogus. It will
That's normal. The net driver model is:
Probe phase (struct pci_driver::probe): * make sure device isn't actively sending irqs or DMA'ing * read MAC address from EEPROM * put device in low power state (D3 is acceptable)
Interface-up (dev->open): * power-up device * allocate consistent DMA memory * request_irq * activate DMA engine * activate link state machine (hardware or software)
Interface-down (dev->stop): * reverse the interface-up steps
So by definition it is a driver bug if the hardware is sending irqs outside of when the driver indicates interest in the irq via request_irq...free_irq.
This is very nice because the sysadmin knows the device is inactive when the interface is down, providing a clear and clean correlation between interface state and hardware state.
In a _very few_ situations, it is impossible to do this because the hardware (or virtual hardware, such as ppc64 hypervisor or s/390) sends interesting (or necessary) events while the interface is down.
> certainly result in problems if the device ever sends an interrupt. And > that seems to be exactly the behaviour you see. > > I suspect that the driver should at the very least make sure to disable > any potentially pending interrupts in the "nv_probe()" function. I have no > idea how to do that, but it looks like something like > > writel(0, base + NvRegIrqMask); > writel(NVREG_IRQSTAT_MASK, base + NvRegIrqStatus);
Agreed; this naturally falls out of the above "Probe phase" description, in a properly written driver.
Also, PCI 2.3 devices have an "interrupt disable" bit in PCI_COMMAND they can use, iff (a) it's implemented and (b) the driver isn't using MSI.
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/
| |