Robert Dunkley
2011-Mar-16 17:16 UTC
[Xen-devel] SR-IOV, Paravirt Guest fails to obtain IRQ after first boot
Hi Everyone, I was wondering if there is a known fix for this issue? HVMs are fine. I''m using the IGB driver and after guest reboot and xm destroy and create I get the following error: msix entry 0 for dev 05:10:0 are not freed before acquire again. msix entry 1 for dev 05:10:0 are not freed before acquire again. msix entry 2 for dev 05:10:0 are not freed before acquire again. msix entry 0 for dev 09:10:0 are not freed before acquire again. msix entry 1 for dev 09:10:0 are not freed before acquire again. msix entry 2 for dev 09:10:0 are not freed before acquire again. I was wondering if this is related to the first RHEL kernel note here: http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/html/5.6_Te chnical_Notes/Known_Issues-kernel-xen.html "A virtual function NIC might fail to get an IP address after several iterations of creating and destroying a guest. To work around this issue, diable interrupt remapping in the system BIOS for kernel-xen." I don''t have a bios setting for that and setting iommu=no-intremap in Dom0 doesn''t help either. Has anyone seen this problem before? Or know how to fix it? Thanks in advance, Rob The SAQ Group Registered Office: 18 Chapel Street, Petersfield, Hampshire GU32 3DZ SAQ is the trading name of SEMTEC Limited. Registered in England & Wales Company Number: 06481952 http://www.saqnet.co.uk AS29219 SAQ Group Delivers high quality, honestly priced communication and I.T. services to UK Business. Broadband : Domains : Email : Hosting : CoLo : Servers : Racks : Transit : Backups : Managed Networks : Remote Support. ISPA Member _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jan Beulich
2011-Mar-17 10:20 UTC
Re: [Xen-devel] SR-IOV, Paravirt Guest fails to obtain IRQ after first boot
>>> On 16.03.11 at 18:16, "Robert Dunkley" <Robert@saq.co.uk> wrote: > Hi Everyone, > > > > I was wondering if there is a known fix for this issue? HVMs are fine. > > I''m using the IGB driver and after guest reboot and xm destroy and > create I get the following error: > msix entry 0 for dev 05:10:0 are > not freed before acquire again. > msix entry 1 for dev 05:10:0 are > not freed before acquire again. > msix entry 2 for dev 05:10:0 are > not freed before acquire again. > msix entry 0 for dev 09:10:0 are > not freed before acquire again. > msix entry 1 for dev 09:10:0 are > not freed before acquire again. > msix entry 2 for dev 09:10:0 are > not freed before acquire again.You didn''t say what kernel you use. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Robert Dunkley
2011-Mar-17 12:56 UTC
RE: [Xen-devel] SR-IOV, Paravirt Guest fails to obtain IRQ after first boot
Hi Jan, Centos 5.5 with 2.6.18-247 RHEL kernel with iommu=pv and the 820 red hat settings among others. Default Centos 5.5 kernel doesn''t detect any VF PCI deviavirt VM. Centos 5.5 with 247 kernel detects and works perfectly first boot but any subsequent boot gives error as below: msix entry 0 for dev 09:10:0 are not freed before acquire again. msix entry 1 for dev 09:10:0 are not freed before acquire again. msix entry 2 for dev 09:10:0 are not freed before acquire again. HVMs are fine with either kernel. Can you give me any idea where the problem might be? Could this be a bios ACPI type issue? Thanks, Rob Below is an xmdmesg extract: [root@missplendid xenvmconfig]# xm dmesg | grep iommu (XEN) Command line: apic_verbosity=debug dom0_mem=2048M dom0_max_vcpus=1 numa=on guest_loglvl=debug iommu=pv msi=1 (XEN) [VT-D]iommu.c:1731:d32767 DMAR: Forcing write-buffer flush (XEN) [VT-D]iommu.c:1233:d32767 domain_context_mapping:PCIe: bdf = 0:0.0 (XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = 0:13.0 (XEN) [VT-D]iommu.c:1233:d32767 domain_context_mapping:PCIe: bdf 0:14.0 (XEN) [VT-D]iommu.c:1233:d32767 domain_context_mapping:PCIe: bdf 0:14.1 (XEN) [VT-D]iommu.c:1233:d32767 domain_context_mapping:PCIe: bdf 0:14.2 (XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = 0:14.3 (XEN) [VT-D]iommu.c:1233:d32767 domain_context_mapping:PCIe: bdf 0:16.0 (XEN) [VT-D]iommu.c:1233:d32767 domain_context_mapping:PCIe: bdf 0:16.1 (XEN) [VT-D]iommu.c:1233:d32767 domain_context_mapping:PCIe: bdf 0:16.2 (XEN) [VT-D]iommu.c:1233:d32767 domain_context_mapping:PCIe: bdf 0:16.3 (XEN) [VT-D]iommu.c:1233:d32767 domain_context_mapping:PCIe: bdf 0:16.4 (XEN) [VT-D]iommu.c:1233:d32767 domain_context_mapping:PCIe: bdf 0:16.5 (XEN) [VT-D]iommu.c:1233:d32767 domain_context_mapping:PCIe: bdf 0:16.6 (XEN) [VT-D]iommu.c:1233:d32767 domain_context_mapping:PCIe: bdf 0:16.7 (XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = 0:1a.0 (XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = 0:1a.1 (XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = 0:1a.2 (XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = 0:1a.7 (XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = 0:1d.0 (XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = 0:1d.1 (XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = 0:1d.2 (XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = 0:1d.7 (XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = 0:1f.0 (XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = 0:1f.3 (XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = 1:0.0 (XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = 1:0.1 (XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = 1:0.2 (XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = 1:0.3 (XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = 1:0.4 (XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = 1:0.5 (XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = 1:0.6 (XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = 1:0.7 (XEN) [VT-D]iommu.c:1233:d32767 domain_context_mapping:PCIe: bdf = 2:0.0 (XEN) [VT-D]iommu.c:1233:d32767 domain_context_mapping:PCIe: bdf = 4:0.0 (XEN) [VT-D]iommu.c:1233:d32767 domain_context_mapping:PCIe: bdf = 5:0.0 (XEN) [VT-D]iommu.c:1233:d32767 domain_context_mapping:PCIe: bdf = 5:0.1 (XEN) [VT-D]iommu.c:1233:d32767 domain_context_mapping:PCIe: bdf = 7:0.0 (XEN) [VT-D]iommu.c:1233:d32767 domain_context_mapping:PCIe: bdf = 7:0.1 (XEN) [VT-D]iommu.c:1233:d32767 domain_context_mapping:PCIe: bdf = 9:0.0 (XEN) [VT-D]iommu.c:1233:d32767 domain_context_mapping:PCIe: bdf = 9:0.1 (XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = ff:0.0 (XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = ff:0.1 (XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = ff:2.0 (XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = ff:2.1 (XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = ff:2.2 (XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = ff:2.3 (XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = ff:2.4 (XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = ff:2.5 (XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = ff:3.0 (XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = ff:3.1 (XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = ff:3.2 (XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = ff:3.4 (XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = ff:4.0 (XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = ff:4.1 (XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = ff:4.2 (XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = ff:4.3 (XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = ff:5.0 (XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = ff:5.1 (XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = ff:5.2 (XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = ff:5.3 (XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = ff:6.0 (XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = ff:6.1 (XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = ff:6.2 (XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = ff:6.3 (XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = 0:1d.0 (XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = 0:1d.1 (XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = 0:1d.2 (XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = 0:1d.7 (XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = 0:1a.0 (XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = 0:1a.1 (XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = 0:1a.2 (XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = 0:1a.7 (XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = 0:1d.0 (XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = 0:1d.1 (XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = 0:1d.2 (XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = 0:1d.7 (XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = 0:1a.0 (XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = 0:1a.1 (XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = 0:1a.2 (XEN) [VT-D]iommu.c:1240:d32767 domain_context_mapping:PCI: bdf = 0:1a.7 (XEN) [VT-D]iommu.c:1233:d0 domain_context_mapping:PCIe: bdf = 9:10.0 (XEN) [VT-D]iommu.c:1233:d0 domain_context_mapping:PCIe: bdf = 9:10.2 (XEN) [VT-D]iommu.c:1233:d0 domain_context_mapping:PCIe: bdf = 9:10.4 (XEN) [VT-D]iommu.c:1233:d0 domain_context_mapping:PCIe: bdf = 9:10.6 (XEN) [VT-D]iommu.c:1233:d0 domain_context_mapping:PCIe: bdf = 9:11.0 (XEN) [VT-D]iommu.c:1233:d0 domain_context_mapping:PCIe: bdf = 9:11.2 (XEN) [VT-D]iommu.c:1233:d0 domain_context_mapping:PCIe: bdf = 9:11.4 (XEN) [VT-D]iommu.c:1233:d0 domain_context_mapping:PCIe: bdf = 9:10.1 (XEN) [VT-D]iommu.c:1233:d0 domain_context_mapping:PCIe: bdf = 9:10.3 (XEN) [VT-D]iommu.c:1233:d0 domain_context_mapping:PCIe: bdf = 9:10.5 (XEN) [VT-D]iommu.c:1233:d0 domain_context_mapping:PCIe: bdf = 9:10.7 (XEN) [VT-D]iommu.c:1233:d0 domain_context_mapping:PCIe: bdf = 9:11.1 (XEN) [VT-D]iommu.c:1233:d0 domain_context_mapping:PCIe: bdf = 9:11.3 (XEN) [VT-D]iommu.c:1233:d0 domain_context_mapping:PCIe: bdf = 9:11.5 (XEN) [VT-D]iommu.c:1233:d0 domain_context_mapping:PCIe: bdf = 5:10.0 (XEN) [VT-D]iommu.c:1233:d0 domain_context_mapping:PCIe: bdf = 5:10.2 (XEN) [VT-D]iommu.c:1233:d0 domain_context_mapping:PCIe: bdf = 5:10.4 (XEN) [VT-D]iommu.c:1233:d0 domain_context_mapping:PCIe: bdf = 5:10.6 (XEN) [VT-D]iommu.c:1233:d0 domain_context_mapping:PCIe: bdf = 5:11.0 (XEN) [VT-D]iommu.c:1233:d0 domain_context_mapping:PCIe: bdf = 5:11.2 (XEN) [VT-D]iommu.c:1233:d0 domain_context_mapping:PCIe: bdf = 5:11.4 (XEN) [VT-D]iommu.c:1233:d0 domain_context_mapping:PCIe: bdf = 5:10.1 (XEN) [VT-D]iommu.c:1233:d0 domain_context_mapping:PCIe: bdf = 5:10.3 (XEN) [VT-D]iommu.c:1233:d0 domain_context_mapping:PCIe: bdf = 5:10.5 (XEN) [VT-D]iommu.c:1233:d0 domain_context_mapping:PCIe: bdf = 5:10.7 (XEN) [VT-D]iommu.c:1233:d0 domain_context_mapping:PCIe: bdf = 5:11.1 (XEN) [VT-D]iommu.c:1233:d0 domain_context_mapping:PCIe: bdf = 5:11.3 (XEN) [VT-D]iommu.c:1233:d0 domain_context_mapping:PCIe: bdf = 5:11.5 -----Original Message----- From: Jan Beulich [mailto:JBeulich@novell.com] Sent: 17 March 2011 10:21 To: Robert Dunkley Cc: xen-devel@lists.xensource.com Subject: Re: [Xen-devel] SR-IOV, Paravirt Guest fails to obtain IRQ after first boot>>> On 16.03.11 at 18:16, "Robert Dunkley" <Robert@saq.co.uk> wrote: > Hi Everyone, > > > > I was wondering if there is a known fix for this issue? HVMs are fine. > > I''m using the IGB driver and after guest reboot and xm destroy and > create I get the following error: > msix entry 0 for dev 05:10:0 are > not freed before acquire again. > msix entry 1 for dev 05:10:0 are > not freed before acquire again. > msix entry 2 for dev 05:10:0 are > not freed before acquire again. > msix entry 0 for dev 09:10:0 are > not freed before acquire again. > msix entry 1 for dev 09:10:0 are > not freed before acquire again. > msix entry 2 for dev 09:10:0 are > not freed before acquire again.You didn''t say what kernel you use. Jan The SAQ Group Registered Office: 18 Chapel Street, Petersfield, Hampshire GU32 3DZ SAQ is the trading name of SEMTEC Limited. Registered in England & Wales Company Number: 06481952 http://www.saqnet.co.uk AS29219 SAQ Group Delivers high quality, honestly priced communication and I.T. services to UK Business. Broadband : Domains : Email : Hosting : CoLo : Servers : Racks : Transit : Backups : Managed Networks : Remote Support. ISPA Member Member _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jan Beulich
2011-Mar-17 14:00 UTC
RE: [Xen-devel] SR-IOV, Paravirt Guest fails to obtain IRQ after first boot
>>> On 17.03.11 at 13:56, "Robert Dunkley" <Robert@saq.co.uk> wrote: > Hi Jan, > > Centos 5.5 with 2.6.18-247 RHEL kernel with iommu=pv and the 820 red hat > settings among others. Default Centos 5.5 kernel doesn''t detect any VF > PCI deviavirt VM. Centos 5.5 with 247 kernel detects and works > perfectly first boot but any subsequent boot gives error as below: > msix entry 0 for dev 09:10:0 are > not freed before acquire again. > msix entry 1 for dev 09:10:0 are > not freed before acquire again. > msix entry 2 for dev 09:10:0 are > not freed before acquire again. > > HVMs are fine with either kernel. > > Can you give me any idea where the problem might be? Could this be a > bios ACPI type issue?Quite possibly your kernel is missing c/s 1070:2994d2997f9d (http://xenbits.xen.org/hg/linux-2.6.18-xen.hg/rev/2994d2997f9d). Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Pasi Kärkkäinen
2011-Mar-17 20:42 UTC
Re: [Xen-devel] SR-IOV, Paravirt Guest fails to obtain IRQ after first boot
On Thu, Mar 17, 2011 at 02:00:01PM +0000, Jan Beulich wrote:> >>> On 17.03.11 at 13:56, "Robert Dunkley" <Robert@saq.co.uk> wrote: > > Hi Jan, > > > > Centos 5.5 with 2.6.18-247 RHEL kernel with iommu=pv and the 820 red hat > > settings among others. Default Centos 5.5 kernel doesn''t detect any VF > > PCI deviavirt VM. Centos 5.5 with 247 kernel detects and works > > perfectly first boot but any subsequent boot gives error as below: > > msix entry 0 for dev 09:10:0 are > > not freed before acquire again. > > msix entry 1 for dev 09:10:0 are > > not freed before acquire again. > > msix entry 2 for dev 09:10:0 are > > not freed before acquire again. > > > > HVMs are fine with either kernel. > > > > Can you give me any idea where the problem might be? Could this be a > > bios ACPI type issue? > > Quite possibly your kernel is missing c/s 1070:2994d2997f9d > (http://xenbits.xen.org/hg/linux-2.6.18-xen.hg/rev/2994d2997f9d). >Robert: Want to open RHEL5 bugzilla entry about this issue? -- Pasi _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Robert Dunkley
2011-Mar-18 08:11 UTC
RE: [Xen-devel] SR-IOV, Paravirt Guest fails to obtain IRQ afterfirst boot
Hi Pasi, Just got your email but I actually opened a Redhat bug last night: https://bugzilla.redhat.com/show_bug.cgi?id=688673 Have collected some additional RH employees for cc but no actual comment yet, looking at other bugs the fact that it has not been rejected yet is probably encouraging. I''m going to try to patch the Centos 5.5 Pciback module myself in the next few hours, hopefully that will get things up and running for me and I won''t be waiting on Redhat. I think Redhat must have some interest in VF pass through to paravirt working otherwise they wouldn''t have applied change set 998/999 between kernels 194 and 247. Thanks, Rob -----Original Message----- From: Pasi Kärkkäinen [mailto:pasik@iki.fi] Sent: 17 March 2011 20:43 To: Jan Beulich Cc: Robert Dunkley; xen-devel@lists.xensource.com Subject: Re: [Xen-devel] SR-IOV, Paravirt Guest fails to obtain IRQ afterfirst boot On Thu, Mar 17, 2011 at 02:00:01PM +0000, Jan Beulich wrote:> >>> On 17.03.11 at 13:56, "Robert Dunkley" <Robert@saq.co.uk> wrote: > > Hi Jan, > > > > Centos 5.5 with 2.6.18-247 RHEL kernel with iommu=pv and the 820 red > > hat settings among others. Default Centos 5.5 kernel doesn''t detect > > any VF PCI deviavirt VM. Centos 5.5 with 247 kernel detects and > > works perfectly first boot but any subsequent boot gives error as below: > > msix entry 0 for dev 09:10:0 are > > not freed before acquire again. > > msix entry 1 for dev 09:10:0 are > > not freed before acquire again. > > msix entry 2 for dev 09:10:0 are > > not freed before acquire again. > > > > HVMs are fine with either kernel. > > > > Can you give me any idea where the problem might be? Could this be a > > bios ACPI type issue? > > Quite possibly your kernel is missing c/s 1070:2994d2997f9d > (http://xenbits.xen.org/hg/linux-2.6.18-xen.hg/rev/2994d2997f9d). >Robert: Want to open RHEL5 bugzilla entry about this issue? -- Pasi The SAQ Group Registered Office: 18 Chapel Street, Petersfield, Hampshire GU32 3DZ SAQ is the trading name of SEMTEC Limited. Registered in England & Wales Company Number: 06481952 http://www.saqnet.co.uk AS29219 SAQ Group Delivers high quality, honestly priced communication and I.T. services to UK Business. Broadband : Domains : Email : Hosting : CoLo : Servers : Racks : Transit : Backups : Managed Networks : Remote Support. ISPA Member _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Robert Dunkley
2011-Mar-18 10:52 UTC
RE: [Xen-devel] SR-IOV, Paravirt Guest fails to obtain IRQ afterfirst boot
Hi Jan, I just wanted to let you know that I applied you patch to pciback and it partially fixes the problem. It seems to me that the Redhat paravirt VM is not properly detaching itself from the VF on clean shutdown or reboot. Redhat have responded and here is the message I left them: I''ve just finished building pciback from the 247 kernel source with the patch. The patch applied cleanly and partially fixes the problem. Abrupt paravirt VM restart is now OK (eg. xm destroy testvm && xm create testvm now works) Clean restart or clean shutdown of the VM and then xm create of VM still shows the problem. Additional information is appearing in Dom console when the failures occur, the VM has 2 Intel 82576 VF assignments from 2 different Intel 82576 lan chips and the increased info in dom0 console looks like this: msix entry 0 for dev 05:10:0 are not freed before acquire again. msix entry 1 for dev 05:10:0 are not freed before acquire again. msix entry 2 for dev 05:10:0 are not freed before acquire again. msix entry 0 for dev 09:10:0 are not freed before acquire again. msix entry 1 for dev 09:10:0 are not freed before acquire again. msix entry 2 for dev 09:10:0 are not freed before acquire again. unmap irq ff failed unmap irq fe failed unmap irq fd failed unmap irq fc failed unmap irq fb failed unmap irq fa failed What is responsible for un-assigning the MSIX IRQ when the VM is shutdown or rebooted? I''m using the igbvf driver that is included with the 247 kernel. Thanks, Rob Dunkley -----Original Message----- From: Pasi Kärkkäinen [mailto:pasik@iki.fi] Sent: 17 March 2011 20:43 To: Jan Beulich Cc: Robert Dunkley; xen-devel@lists.xensource.com Subject: Re: [Xen-devel] SR-IOV, Paravirt Guest fails to obtain IRQ afterfirst boot On Thu, Mar 17, 2011 at 02:00:01PM +0000, Jan Beulich wrote:> >>> On 17.03.11 at 13:56, "Robert Dunkley" <Robert@saq.co.uk> wrote: > > Hi Jan, > > > > Centos 5.5 with 2.6.18-247 RHEL kernel with iommu=pv and the 820 red > > hat settings among others. Default Centos 5.5 kernel doesn''t detect > > any VF PCI deviavirt VM. Centos 5.5 with 247 kernel detects and > > works perfectly first boot but any subsequent boot gives error as below: > > msix entry 0 for dev 09:10:0 are > > not freed before acquire again. > > msix entry 1 for dev 09:10:0 are > > not freed before acquire again. > > msix entry 2 for dev 09:10:0 are > > not freed before acquire again. > > > > HVMs are fine with either kernel. > > > > Can you give me any idea where the problem might be? Could this be a > > bios ACPI type issue? > > Quite possibly your kernel is missing c/s 1070:2994d2997f9d > (http://xenbits.xen.org/hg/linux-2.6.18-xen.hg/rev/2994d2997f9d). >Robert: Want to open RHEL5 bugzilla entry about this issue? -- Pasi The SAQ Group Registered Office: 18 Chapel Street, Petersfield, Hampshire GU32 3DZ SAQ is the trading name of SEMTEC Limited. Registered in England & Wales Company Number: 06481952 http://www.saqnet.co.uk AS29219 SAQ Group Delivers high quality, honestly priced communication and I.T. services to UK Business. Broadband : Domains : Email : Hosting : CoLo : Servers : Racks : Transit : Backups : Managed Networks : Remote Support. ISPA Member _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel