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().
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?
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).
Thanks,
Don
diff --git a/drivers/pci/search.c b/drivers/pci/search.c
index ec41535..874c975 100644
--- a/drivers/pci/search.c
+++ b/drivers/pci/search.c
@@ -209,7 +209,6 @@ static struct pci_dev *pci_get_dev_by_id(const struct pci_device_id *id,
struct device *dev_start = NULL;
struct pci_dev *pdev = NULL;
- WARN_ON(in_interrupt());
if (from)
dev_start = &from->dev;
dev = bus_find_device(&pci_bus_type, dev_start, (void *)id,
--
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
