On Thu, May 28, 2009 at 09:42:23AM -0400, Prarit Bhargava wrote:
> An RH customer noted that the reported IRQ value from 'lspci -xxx -vv'
> and the value from /proc/interrupts do not match on devices with MSI or
> MSI-X (MSI/-X). This issue also occurs upstream.
It works fine upstream for MSI:
26: 2058782 2060232 PCI-MSI-edge ahci
00:1f.2 SATA controller: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) SATA AHCI Controller (rev 03) (prog-if 01 [AHCI 1.0])
Subsystem: Fujitsu Limited. Device 1411
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 26
It doesn't work for MSI-X, no. There have been proposals to fix this
in the past involving sysfs, but the patches haven't been pushed far
enough to be merged.
> I think the logical thing to do is to create a /sysfs PCI device file
> which exports this data so that lspci can use it and report MSI/-X
> values.
>
> For example,
>
> /sys/devices/pci0000:00/0000:00:0f.0/0000:03:00.0/msi_irq would contain
> "msix 74 82"
>
> (If the device only had MSI enabled, the file would contain "msi 74")
>
> I'm using "msi_irq" following the convention in the pci msi code which
> uses msi as a name when both MSI and MSI-X can be used.
>
> Any obvious drawbacks to this? Comments?
You could start by reading http://marc.info/?t=122516333900004&r=1&w=2
which will bring you up to speed on all the previous discussion around
this topic ;-)
--
Matthew Wilcox Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
--
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
