On Thu, Jun 17, 2010 at 04:43:13PM -0400, Don Zickus wrote:
> I have been trying to track down sources of unknown NMIs and spurious
> interrupts recently using old fashion detective work of inspecting all
> devices on the PCI bus to see what ERR/INT bits are set.
>
> Using a for-loop like this inside an NMI or interrupt context:
>
> err_bits = <some interesting value>
> while ((dev = pci_get_device(PCI_ANY_ID, PCI_ANY_ID, dev)) != NULL) {
> pci_read_config_word(dev,0x6,&data);
> if (data & err_bits)
> printk(...<found what i was looking for>...);
> }
>
> Of course every time this code gets executed the I get bit by the
> WARN_ON(in_interrupt) inside of pci_get_dev_by_id().
Yup, because that call can sleep.
> I was trying to figure out why it was there. I don't see any locks inside
> the call path or anything else that might be a no-no inside an interrupt
> context. Perhaps I missed something? Or is there a better way to do what
> I want to do calling lower level functions?
The bus_find_device() call can sleep with the klist iterations that will
happen.
This very issue came up a few months ago, check the archives :)
> I understand my code is hack'ish and there could be other sources of NMIs
> or interrupts but for debugging purposes it sure is helping debug a bunch
> of problems (related to firmware).
Can't you get a better idea of which pci device caused the NMI without
having to walk over every device in the system? Remember, PCI devices
can be removed at any point in time :)
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
