Re: WARNING at drivers/pci/search.c:214 for 3.9

[Borislav Petkov <bp@alien8.de>]

On Mon, May 06, 2013 at 09:20:04PM +0000, Ortiz, Lance E wrote:
> Right Boris, looks like we are hitting the WARN_ON(in_interrupt)
> in pci_get_dev_by_id(). We recently started seeing this on our
> test systems when injecting errors.

Ok, I think I have it. That comes from cper_print_pcie(), i.e. your
enhanced PCIe logging in 1d5210008bd3a26daf4b06aed9d6c330dd4c83e2 which
came in 3.9. And since 3.9 is just out now, people are starting to see
the issue.

If you look at the call stack, you land in cper_print_pcie() down
from ghes_proc() which can be called from the polling routine
ghes_poll_func() but also from the interrupt handler ghes_irq_func.

> The only reason we are calling pci_get_domain_bus_and_slot() is to get
> the pci_dev* to pass into cper_print_aer() so we can have the device's
> name to put into the trace event for AER. If we can find another way
> to get the device name for the trace event we could remove this call
> to pci_get_domain_bus_and_slot(). I will continue to look into an
> alternative. If you have any ideas on how to get the device data from
> this context let me know.

Hmm, not sure.

Off the top of my head, maybe add the whole code around:

#ifdef CONFIG_ACPI_APEI_PCIEAER
...

#endif

in cper_print_pcie() into a separate function which is called from a
workqueue right after the interrupt is done.. Or something to that
effect.

> I'm not sure why the pci_get_domain_bus_and_slot() is failing to find
> the PCI device though. We are not hitting that issue. We are just
> seeing the in_interrupt warning.

Well, it could be corrupted error info or such because it used to say

[   65.782664] {1}[Hardware Error]: device_id: 0000:00:02.3

but he doesn't have a 02.3 device in the lspci output.

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--