> -----Ursprüngliche Nachricht-----
> Von: Greg Rose [mailto:[email protected]]
> Gesendet: Mittwoch, 31. Oktober 2012 17:10
> An: Richter, Andre
> Cc: [email protected]; Rauchfuss, Holm; Herber, Christian
> Betreff: Re: [E1000-devel] MSI-X capability of 82576 VFs
>
> On Wed, 31 Oct 2012 13:29:08 +0000
> "Richter, Andre" <[email protected]> wrote:
>
> > Hi all,
> >
> > I am trying to get my 82576 Virtual Functions to work under Xen 4.2 on
> > an Intel DQ77MK Motherboard (I have to use pci=assign-busses to make
> > the VFs show up). My machine reproduces what has been posted here a
> > while ago:
> > http://old-list-archives.xen.org/archives/html/xen-devel/2011-03/msg00
> > 063.html I get MSI-X for the PF, but INTx for the VFs. Unfortunately,
> > the suggested solution of adding acpi=0 to the config file does not
> > work for me.
>
> From the information below you seem to be missing MSIX support. It would
> look something like this:
>
> Capabilities: [70] MSI-X: Enable+ Count=64 Masked-
> Vector table: BAR=4 offset=00000000
> PBA: BAR=4 offset=00002000
>
> The bridge device your 82576 is connected to needs to support MSIX.
> I'm having a hard time figuring out how the PF gets MSIX when the upstream
> bridge doesn't support it. I didn't think that would work.
>
> - Greg
Hi Greg,
I may have a better idea now what's going on:
MSI(-X) Spec says that MSI(-X) interrupts look like normal PCI DWORD memory
write transactions.
Therefore, a bridge most certainly does not know if it is forwarding an MSI
interrupt or not, it just does.
I think the capability registers of a bridge showing MSI oder MSI-X support
only tell that the bridge itself is able to fire MSI(-X) interrupts.
Maybe a bridge does not need to have these capabilities to show up in the PCI
configuration space to route MSI(-X) interrupts.?
I also found this in the Linux source code inside drivers/pci/msi.c:
* Any bridge which does NOT route MSI transactions from its
* secondary bus to its primary bus must set NO_MSI flag on
* the secondary pci_bus.
* We expect only arch-specific PCI host bus controller driver
* or quirks for specific PCI bridges to be setting NO_MSI.
*/
for (bus = dev->bus; bus; bus = bus->parent)
if (bus->bus_flags & PCI_BUS_FLAGS_NO_MSI)
return -EINVAL;
It seems that a bridge should explicitly state if it is not able to route
MSI(-X) interrupts.
Best Regards,
Andre
>
> >
> > This is the bridge the NIC is connected to:
> >
> > 00:1c.0 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset
> > Family PCI Express Root Port 1 (rev c4) (prog-if 00 [Normal decode])
> > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> ParErr-
> > Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B-
> > ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
> > Latency: 0, Cache Line Size: 64 bytes Bus: primary=00, secondary=03,
> > subordinate=03, sec-latency=0 I/O behind bridge: 0000f000-00000fff
> > Memory behind bridge: fff00000-000fffff Prefetchable memory behind
> > bridge: 00000000fff00000-00000000000fffff Secondary status: 66MHz-
> > FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
> > BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
> > PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities:
> > [40] Express (v2) Root Port (Slot+), MSI 00 DevCap: MaxPayload 128
> > bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us ExtTag- RBE+ FLReset-
> > DevCtl: Report errors: Correctable- Non-Fatal- Fatal-
> > Unsupported- RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
> > MaxPayload 128 bytes, MaxReadReq 128 bytes
> > DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq-
> > AuxPwr+ TransPend- LnkCap: Port #1, Speed 5GT/s, Width x4, ASPM L0s
> > L1, Latency L0 <1us, L1 <16us ClockPM- Surprise- LLActRep+ BwNot-
> > LnkCtl: ASPM L0s L1 Enabled; RCB 64 bytes Disabled-
> > Retrain- CommClk- ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
> > LnkSta: Speed 2.5GT/s, Width x0, TrErr- Train-
> > SlotClk+ DLActive- BWMgmt- ABWMgmt- SltCap: AttnBtn- PwrCtrl- MRL-
> > AttnInd- PwrInd- HotPlug- Surprise- Slot #0, PowerLimit 25.000W;
> > Interlock- NoCompl+ SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet-
> > CmdCplt- HPIrq- LinkChg- Control: AttnInd Unknown, PwrInd Unknown,
> > Power- Interlock- SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt-
> > PresDet- Interlock- Changed: MRL- PresDet- LinkState-
> > RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal-
> > PMEIntEna- CRSVisible- RootCap: CRSVisible-
> > RootSta: PME ReqID 0000, PMEStatus- PMEPending-
> > DevCap2: Completion Timeout: Range BC, TimeoutDis+
> > ARIFwd- DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- ARIFwd-
> > LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance-
> > SpeedDis-, Selectable De-emphasis: -6dB Transmit Margin: Normal
> > Operating Range, EnterModifiedCompliance- ComplianceSOS- Compliance
> > De-emphasis: -6dB LnkSta2: Current De-emphasis Level: -3.5dB,
> > EqualizationComplete-, EqualizationPhase1- EqualizationPhase2-,
> > EqualizationPhase3-, LinkEqualizationRequest- Capabilities: [80] MSI:
> > Enable- Count=1/1 Maskable- 64bit- Address: 00000000 Data: 0000
> > Capabilities: [90] Subsystem: Intel Corporation Device 2035
> > Capabilities: [a0] Power Management version 2
> > Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
> > PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 NoSoftRst- PME-Enable-
> > DSel=0 DScale=0 PME- Kernel driver in use: pcieport
> > Kernel modules: shpchp
> >
> > Any ideas what might be the cause I'm only getting INTx interrupts?
> >
> > Best Regards,
> > Andre
> >
> >
------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
_______________________________________________
E1000-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit
http://communities.intel.com/community/wired